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 — default-permissive entities mean every authenticated user reads every record without explicit ownership filters. 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 is everywhere because the platform ships permissive defaults with no native CSP or HSTS. A07 Identification and Authentication Failures was demonstrated by the July 2025 Wiz SSO bypass. A09 Insufficient Logging is structural because platform logs are shallow and short-retention. 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. By default, Entity.list() returns every record in the entity, scoped only by entity name. There is no implicit per-user filtering. Update and delete operations also do not check ownership server-side. This means: any authenticated user can read every record, update any record by ID, and delete any record by ID, unless you have explicitly added authorization logic.

What it looks like in code:

// Vulnerable: returns every Order in the system, not just the current user's.
const orders = await base44.entities.Order.list();

// Vulnerable: client tells the server which user_id to use, server trusts it.
await base44.entities.Order.update(orderId, { status: "refunded" });

Mitigation:

1. Every list call gets an explicit ownership filter: Entity.list({ created_by: currentUser.email }).
2. Every update and delete goes through a backend function that re-fetches the record, verifies record.created_by === currentUser.email, and only then allows the change.
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.
5. Add ESLint rules in your repo to flag any Entity.list() call without a filter argument.

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 platform's default trust model is the design issue.

Specific issues:

• Default-permissive entities. Designing for permissive defaults is a deliberate platform choice for prototyping speed, but it shifts every secure-design responsibility to the engineer.
• 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. Build security-by-default helpers and use them everywhere: safeList(entityName, filter) instead of Entity.list(), with the helper enforcing ownership filters.
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. Pervasive. The platform ships with many permissive defaults that are appropriate for prototyping and wrong for production.

Specific issues:

• No HSTS header. The platform doesn't add Strict-Transport-Security. Add via CDN proxy.
• No strict CSP. No way to configure Content-Security-Policy natively.
• No X-Frame-Options or frame-ancestors. Clickjacking-vulnerable by default.
• Verbose error messages. Default error responses leak implementation details.
• Default visibility on entities. Already covered as A01.
• Verbose stack traces in development that may persist into production.
• No rate limiting on registration or password reset.

Mitigation:

1. Put Cloudflare or a similar CDN in front of your custom domain. Add HSTS, CSP, X-Frame-Options, Referrer-Policy, Permissions-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 MFA enforcement at the role level. Per-user MFA is opt-in.
• 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 MFA for any admin or privileged role. Audit weekly that admins have MFA enabled.
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. Severe. Platform logs are shallow and short-retention.

Specific issues:

• No detailed audit log of admin actions. Who changed which entity schema and when is not natively logged.
• Backend function logs roll quickly. Hours to days, not months.
• No native security event correlation. Failed logins, privilege escalations, anomalous access — not aggregated or alerted on.

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	Most common cause
A01 Broken Access Control	Critical	Default-permissive entities
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	Permissive defaults at platform level
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	Shallow 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 platform's logs do not satisfy A09. Ship them 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 or build 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.