OWASP Top 10 in Base44: How Each Risk Manifests in 2026

OWASP Top 10 risks manifest in platform-specific ways on Base44. A01 Broken Access Control is the most severe — Base44's AI sets each entity's access rules as it builds, and a rule broader than the data needs lets an ordinary account read other users' records. A02 Cryptographic Failures appears as JWTs in localStorage and sensitive fields that the platform encrypts at rest but that any request passing your access rules reads in the clear. A03 Injection is reduced by the SDK but XSS via dangerouslySetInnerHTML and LLM prompt injection still apply. A05 Security Misconfiguration shows up in settings left as generated and in headers you cannot set per app: Base44 offers X-Frame-Options and Permissions-Policy settings, but no per-app CSP or HSTS. A07 Identification and Authentication Failures was demonstrated by the July 2025 Wiz SSO bypass. A09 Logging is only partly covered: each app's Logs page records user and schema events, but the docs give it no retention period or alerting. Each risk requires explicit engineering work; the platform does not solve them by default.

Why this matters

OWASP Top 10 is the canonical framework for thinking about web application security risks. It is not a checklist, exactly — it is a prioritized list of risk categories, each with multiple sub-issues. For Base44 apps, several of these risks manifest in platform-specific ways that generic OWASP guides do not address. This article, from the lead engineer at Base44Devs, maps each category to what it actually looks like on Base44, with concrete mitigations.

We use the OWASP 2021 Top 10 because it is the most widely-adopted version as of 2026 and the version most security audits and compliance frameworks reference.

A01 Broken Access Control (highest severity on Base44)

OWASP definition: Restrictions on what authenticated users are allowed to do are not properly enforced.

Base44 manifestation. The single most consequential risk on the platform. Access control lives in each entity's rules: row-level rules for create, read, update and delete, plus optional field-level rules in the schema. Base44's AI writes those rules as it builds, and they can be broader than the data needs; an entity with no rules at all is open, since Base44's CLI reference warns that "if no RLS is defined, all records are accessible to all users." A Read rule left on All Users lets anyone list the table, even without signing in; an Update or Delete rule with no ownership check lets any signed-in user change or remove any record by ID. Backend functions add a second path: code that uses base44.asServiceRole bypasses every entity rule, so it must run its own authorization checks.

What it looks like in code:

// Vulnerable when Order's Read rule is too broad (for example All Users):
// this returns every Order in the system, not just the current user's.
const orders = await base44.entities.Order.list();

// Vulnerable when Order's Update rule has no ownership check: any signed-in
// user can refund any order by ID. Even with Creator Only, the buyer can still
// change their own order's status unless a field-level rule blocks it, so status
// changes belong in a backend function.
await base44.entities.Order.update(orderId, { status: "refunded" });

Mitigation:

1. Open every table's Permissions page and set each action to the narrowest rule that works: Creator Only for personal data, Entity-User Field Comparison for assigned or tenant records, User Property Check for admin-only tables. All Users belongs only on genuinely public data.
2. Every update and delete that carries a business rule (status, refunds, balances) goes through a backend function that re-fetches the record, verifies record.created_by === currentUser.email and the allowed transition, and only then writes. If that function uses asServiceRole, this check is the only control.
3. Strip dangerous fields (role, permissions, tier) from any client-initiated update.
4. Test with a fresh second account that owns nothing. Every list and read should return zero results. Test Permissions in preview, on each table's Permissions page, runs the same check from the dashboard.
5. Run Base44's security scan: it flags tables that are missing permission rules or give people more access than they should, and backend functions anyone can call without signing in.

Severity if missed: Critical. Customer data exposure. This is the highest-impact category we audit for.

A02 Cryptographic Failures

OWASP definition: Sensitive data is exposed because of weak or missing cryptographic protection in transit or at rest.

Base44 manifestation. TLS in transit is handled automatically. The cryptographic failures are at rest and at the token layer.

Specific issues:

• JWTs in local storage. Base44's security overview says it "stores authentication tokens in the browser's localStorage. HttpOnly cookie storage is not currently available." Any in-page script can read them. Imperva's August 2025 disclosure showed why that matters: its stored-XSS payload ran inside app.base44.com, and "Since the payload executed inside the trusted domain, it had access to authentication tokens stored in the browser local storage, and other sensitive data." The platform-level fix is httpOnly cookies; until that ships, tokens are exposed.
• Sensitive fields encrypted by the platform, not by you. Base44 encrypts app data at rest with AES-256 and in transit with TLS 1.2+ (base44.com/security), but its docs add that "data is not end-to-end encrypted, which means Base44 admins can access your data if needed", and every request that passes your app's access rules gets the field back in the clear. For PII (SSN, birthdate), platform encryption alone is often not enough for many enterprise contracts, and Base44's terms of service bar protected health information and payment card data from the platform unless Base44 has expressly agreed in writing.
• No native column-level encryption. You cannot tell Base44 "encrypt this column with a key I control." Enterprise workspaces can get a dedicated encryption key, but the security overview describes it for workspace secrets such as API keys and integration credentials, not for your table data.

Mitigation:

1. Shorten JWT TTL to 15 minutes. Rotate on privileged actions. Refuse to render any user-supplied HTML.
2. For sensitive fields, encrypt client-side or server-side with a key held in backend function environment variables. Decrypt on read in backend functions, never on the client.
3. Use a third-party secrets vault (1Password Connect, AWS Secrets Manager, Doppler) for the encryption keys, not Base44's environment variable storage.
4. For payment data, use Stripe Elements and never let card data touch Base44 storage.

Severity if missed: High to Critical depending on data sensitivity.

A03 Injection

OWASP definition: Untrusted data is sent to an interpreter as part of a command or query.

Base44 manifestation. Reduced but not eliminated.

What's mostly handled:

• The Base44 SDK's filter syntax doesn't expose raw SQL. Direct SQL injection against entities is not generally possible.
• HTML in entity fields, when rendered through React's default escaping, is safe.

What is still an issue:

• HTML rendered as dangerouslySetInnerHTML. Any user-controlled field rendered without escaping is XSS-prone. Imperva's August 2025 stored-XSS finding was the platform-level version: because code editing was only enforced client-side, attacker JavaScript could be saved into an app and then ran inside app.base44.com when the app was viewed.
• Markdown rendered without sanitization. If you render user-supplied markdown, the output may contain unsanitized HTML.
• Backend function code that builds external API queries from user input. A backend function that calls an external service with user-controlled query parameters can be injection-vulnerable to that service.
• LLM prompt injection. User-controlled text passed to invokeLLM can hijack the prompt and exfiltrate data or trigger unintended actions.

Mitigation:

1. Never use dangerouslySetInnerHTML with user content. If you must, run through DOMPurify with an allow-list.
2. For markdown, use a renderer with html: false (markdown-it) or similar.
3. Validate and sanitize every user input that flows into an external API call from a backend function.
4. For LLM prompts, structure user input as data, not as instructions: prompt = "Process this user-supplied text: <text>" + escaped(userText). Use system prompts to constrain behavior. Treat LLM output as untrusted.

Severity if missed: Critical for auth-token-leaking XSS, lower for prompt injection (depends on what the LLM can do).

A04 Insecure Design

OWASP definition: Risks related to design and architectural flaws, with a focus on threat modeling, secure design patterns, and reference architectures.

Base44 manifestation. The design issue is who sets the trust model: unless you step in, the AI does.

Specific issues:

• AI-generated access rules. Base44 sets data permissions automatically as you build, from what the AI infers from your prompts, not from a threat model. Its security overview is explicit that you are responsible for your app's security settings.
• No threat modeling at the platform level. Apps inherit the platform's threat model assumptions, which are oriented toward indie prototyping, not production.
• AI agent emits insecure-by-default code. The agent's training data biases toward generated code that compiles and looks plausible, not toward code that is secure under hostile conditions.

Mitigation:

1. Run a threat model on every app before launch. Who are your users, who are your adversaries, what are you protecting?
2. Treat agent-generated code as a draft. Review every security-relevant change.
3. Put enforcement in each entity's access rules and in backend functions, not in client-side helpers such as a safeList() wrapper: anyone can call the SDK directly.
4. Document the threat model in the repo. Make it part of the onboarding for new contributors.

Severity if missed: Variable. Insecure design enables every other risk; bad design plus good implementation still produces vulnerabilities.

A05 Security Misconfiguration

OWASP definition: Insecure default configurations, incomplete configurations, open cloud storage, misconfigured HTTP headers.

Base44 manifestation. Concentrated in headers you cannot set per app and in settings nobody revisited after the AI generated them.

Specific issues:

• No per-app HSTS setting. Base44's security overview says Strict-Transport-Security is not configurable at the individual app level. Check what your domain sends, and add your own policy via CDN proxy.
• No strict CSP. The same overview says Content-Security-Policy is not configurable per app either.
• X-Frame-Options has to be switched on. Base44's Browser Security settings control iframe embedding, and the security scan flags the header when it is missing; the same card's Protect camera and location switch covers Permissions-Policy.
• Verbose error messages. Default error responses leak implementation details.
• App visibility left at the workspace default. Base44's developer docs say a new app's visibility follows the workspace default, which for most workspaces is public without login. Set it deliberately; entity rules are covered under A01.
• Verbose stack traces in development that may persist into production.
• Rate limits are the platform's. Base44 rate-limits all public endpoints by default, with no configuration required on your part; if you need stricter per-account limits on login, registration or password reset, you add them.

Mitigation:

1. Turn on X-Frame-Options and Permissions-Policy under Browser Security, then put Cloudflare or a similar CDN in front of your custom domain for HSTS, CSP and Referrer-Policy.
2. Wrap every backend function in a try/catch that returns a generic 500 to clients while logging detail externally.
3. Add explicit rate limiting on registration, password reset, and login endpoints.
4. Run a security headers scan (securityheaders.com, mozilla observatory) at least monthly.

Severity if missed: High.

A06 Vulnerable and Outdated Components

OWASP definition: Use of components with known vulnerabilities.

Base44 manifestation. You don't directly manage React, Deno runtime, or platform infrastructure versions. You do manage your package.json dependencies (if you use any) and the npm/JSR packages your backend functions import.

Specific issues:

• You can't audit the platform's component versions. What version of React, what version of the Deno runtime, what version of the underlying database? Not published in detail.
• Backend function imports are user-managed. Any vulnerable npm package you import is on you.
• Front-end dependencies the agent adds. The agent sometimes pulls in npm packages with known issues.

Mitigation:

1. Keep your package.json dependencies current. Run npm audit weekly.
2. Pin backend function imports to specific versions. Audit them quarterly.
3. Subscribe to Base44's changelog and security advisories (such as they are).
4. Have a documented procedure for responding to a CVE in a platform-managed component (which is "wait for the platform to patch and verify").

Severity if missed: Medium to High.

A07 Identification and Authentication Failures

OWASP definition: Confirmation of user identity, authentication, or session management is implemented incorrectly.

Base44 manifestation. The July 2025 SSO bypass was a textbook A07 failure. The class of issue persists in some defaults.

Specific issues:

• The SSO bypass. Patched, but illustrative: undocumented registration and email-verification endpoints accepted sign-ups for a private app from anyone who supplied its app_id (Wiz, July 2025).
• Email enumeration via password reset. Default reset endpoints have leaked whether an email exists.
• No documented MFA for app users. Base44's two-factor authentication covers Base44 accounts (your builders), and Business or Enterprise workspaces can require it for members; the docs describe nothing equivalent for the people who sign in to your app.
• Session timeout on the client only. A backend function does not by default re-validate session age.
• Password complexity rules are platform-default. May not meet your industry's standards.

Mitigation:

1. After any signup, re-verify the email's domain against your allowed list in a backend function.
2. Wrap the password reset flow to return a generic response regardless of email existence.
3. Require 2FA on every builder account (workspace-wide on Business or Enterprise). For admin roles in the live app, add a second factor yourself or sign admins in through an identity provider that enforces MFA, and audit enrollment weekly.
4. Add a backend-function session-age check. Reject tokens older than your policy.
5. Enforce your own password complexity rules in a backend function before allowing creates.

Severity if missed: Critical.

A08 Software and Data Integrity Failures

OWASP definition: Code and infrastructure that does not protect against integrity violations, e.g., insecure deserialization, untrusted updates.

Base44 manifestation.

• AI agent regression introduces unintended changes. The agent rewriting working code is functionally a software integrity issue: the running code no longer matches what was reviewed and approved.
• Unsigned platform updates. Base44 platform updates ship without signature verification on your side.
• Untrusted webhook payloads. Inbound webhooks from third parties are signed (Stripe, etc.), but only if you verify the signatures.

Mitigation:

1. Snapshot before every agent turn. Maintain a known-good code state.
2. Verify webhook signatures from every third party. Reject unsigned or mis-signed payloads.
3. Lock critical-path code behind explicit prompt directives or move it to backend functions the agent rarely touches.
4. Subscribe to Base44's status page and changelog. React to platform changes deliberately.

Severity if missed: Medium to High.

A09 Security Logging and Monitoring Failures

OWASP definition: Insufficient logging, detection, and response capabilities.

Base44 manifestation. Partly covered. Each app has a Logs page, but the docs give it no retention period and describe no alerting.

Specific issues:

• App-level changes are logged; workspace-level ones need Enterprise. The Logs page's Setup category records entity schema changes, publishes and integration setup alongside the user who made them, and its Runtime category records logins, role changes and record creates, updates and deletes. Workspace events such as member and billing changes come only through the Enterprise plan's Audit Logs API.
• Function logs are kept for a limited time. Base44's function-logs API returns up to 500 lines from the last 7 days by default and warns that older windows can come back empty; no retention period is published.
• Events are recorded, not correlated. Logins and role changes appear in the Logs page, but the docs describe no aggregation or alerting on them.

Mitigation:

1. Ship every backend function's logs out via fetch to an external SIEM.
2. Build an AuditLog entity, populate it from every privileged backend function call.
3. Wire Sentry for frontend errors.
4. Set up alerts for: failed-auth bursts (>5 from one IP in a minute), new admin role assignments, anomalous data access volumes, credit burn anomalies.
5. Retain logs for at least 90 days. Longer if regulatory requirements apply.

Severity if missed: High. Without logging, you cannot detect or respond to incidents.

A10 Server-Side Request Forgery (SSRF)

OWASP definition: A web app fetches a remote resource without validating the user-supplied URL.

Base44 manifestation. Backend functions that take user-supplied URLs and fetch them are SSRF-vulnerable.

Specific issues:

• Image proxy backend functions. A function that fetches an image from a user-supplied URL can be coerced into hitting internal URLs.
• Webhook URL validation. If your app accepts webhook URLs from users, the URLs need validation.
• OAuth callback URLs. Insufficient validation can enable open redirect to attacker-controlled domains.

Mitigation:

1. Validate user-supplied URLs against an allow-list before fetching.
2. Reject 127.0.0.1, localhost, 169.254.169.254 (cloud metadata), and private IP ranges.
3. Use a separate egress proxy with deny rules rather than fetching directly.
4. For OAuth, strict allow-list of callback URLs.

Severity if missed: High when present, but not always present in every app.

OWASP scoring summary

Risk	Severity on Base44	Common cause
A01 Broken Access Control	Critical	Entity rules broader than the data needs
A02 Cryptographic Failures	High	JWTs in local storage, PII without field-level encryption
A03 Injection	Medium-High	XSS via dangerouslySetInnerHTML or markdown
A04 Insecure Design	Variable	AI-set rules nobody threat-modeled
A05 Security Misconfiguration	High	Missing security headers
A06 Vulnerable Components	Medium	Unpinned backend function imports
A07 Identification Failures	Critical	The SSO bypass class of issue
A08 Software/Data Integrity	Medium	AI agent regressions, missing webhook sig validation
A09 Logging Failures	High	No retention promise or alerting on platform logs
A10 SSRF	Variable	URL fetches in backend functions

Common OWASP audit mistakes on Base44

Treating SDK-mediated calls as inherently safe. They are safer than raw SQL but not free of injection risk.

Skipping the second-account test for A01. This is the single highest-leverage 30 minutes of an OWASP audit.

Ignoring A09 because "the platform has logs." The Logs page is a good start, but with no documented retention or alerting it does not satisfy A09 on its own. Ship security events out.

Treating A04 as theoretical. Insecure design enables every other category. Threat-model your app.

Auditing once and never again. OWASP risks reappear with every code generation pass and every schema change. Quarterly cadence minimum.

Want us to run an OWASP audit on your Base44 app?

Our $497 production audit walks all ten OWASP categories, runs second-account tests for A01, scans headers for A05, and verifies logging coverage for A09. Delivered as a written report with severity scores per finding, and the fee is credited in full against any fix, build, migration or written-recommendation engagement booked within 30 days. Order an audit or book a free 15-minute call.

Related reading

• Base44 Security Hardening Checklist — the 32-item drill-down covering A01–A10 in concrete steps.
• Base44 Authentication Patterns — the auth-flow patterns that cover A07.
• Base44 Production Readiness Guide — the broader operational picture, of which OWASP coverage is one pillar.
• Is My Base44 App Secure? — an overall security assessment of your app that summarizes where these OWASP risks leave your exposure.