OWASP Top 10 for AI-Built Apps: What Vibe Coders Need to Know

Quick answer: Use the OWASP Top 10 to organize a review of your app's access controls, input handling, dependencies, configuration, and failure behavior. Generated code needs these checks too. The appropriate controls depend on the architecture; a scan or one database setting does not cover every category.

By Daniel A · Kraftwire Software

Use the OWASP Top 10 to organize a review of your app's access controls, input handling, dependencies, configuration, and failure behavior. Generated code needs these checks too. The appropriate controls depend on the architecture; a scan or one database setting does not cover every category.

This guide uses the OWASP Top 10:2025 category names. Apply them to the code and deployed behavior of your app, whether you used a visual builder, an AI editor, or manual development. The examples are review prompts, not a complete verification checklist.

A01: Broken Access Control

Broken Access Control concerns missing or incorrect authorization checks. Review generated code and deployment configuration independently of whether the visible features work. See vibe coding.

How It Shows Up in an App

Test server-side authentication and authorization for each protected operation. An endpoint such as /api/admin/delete-user needs permission checks even if its UI control is hidden. The leading space in this illustrative inline label is not part of the route.

The Fix: Server-Side Enforcement

Enforce permissions at the backend or data layer for each protected operation. Row Level Security (RLS) can help in a Postgres-based design, but it is not a universal requirement for every architecture. Frontend visibility does not replace authorization.

A04: Cryptographic Failures

This category involves the protection of data in transit and at rest. Review generated code and deployment settings directly; the scan corpus does not measure model priorities or establish why a finding occurred.

How It Shows Up in an App

Review encrypted transport, storage protection, password handling, and key management. Keep secret credentials out of client bundles and public repositories. An SSL/TLS check inspects transport signals, not every use of cryptography in your application.

The Fix: Established Implementations

Use maintained libraries and platform services suited to the task, with documented settings and key management. Password hashing and reversible encryption solve different problems. A secret scanner can find supported exposure patterns, but it does not verify the correctness of all cryptographic choices.

A05: Injection Attacks

Injection occurs when untrusted data changes the meaning of a command or query sent to an interpreter. Review raw query construction and command execution whether the code is generated or handwritten.

How It Shows Up in an App

A query constructed as "SELECT * FROM users WHERE name = '" + userInput + "'" mixes user text with SQL syntax. This illustrates SQL injection risk if the resulting query is executed without a safe parameter interface. See injection prevention.

The Fix: Parameterization

Use parameterized interfaces for query values, including when working through an ORM. An ORM can still expose unsafe raw-query paths. Validate identifiers or other query structure against allowed values, and separately enforce database permissions.

A06: Insecure Design

Insecure design is a broad category that focuses on flaws in the application's logic and architecture rather than just the code implementation.

How It Shows Up in an App

A referral system may permit abuse if it lacks rules for eligibility, repeated claims, or automated requests. Define those rules before implementation and test attempts to bypass them; a feature request alone does not establish its security requirements.

The Fix: Review Abuse Cases

Define who may perform each action, what resources it consumes, and how failures should behave. Consider usage limits and account protections appropriate to the workflow. Use the vibe-coding security checklist to organize tests, including risks outside automated coverage.

A02: Security Misconfiguration

Security misconfiguration includes settings that expose unnecessary functionality, sensitive details, or unintended access. Review defaults and deployed settings against the app's requirements.

How It Shows Up in an App

Check whether a debug setting such as DEBUG=true exposes sensitive errors or interactive diagnostics. Review returned security headers and the browser protections they actually apply. Do not infer prevalence from the coding tool used.

The Fix: Harden Deployed Settings

Disable publicly exposed development diagnostics and limit detailed errors to appropriate logs. A CSP generator can draft a policy that you must test against the app. SimplyScan checks supported headers and exposed-file patterns in resources it reaches; it does not establish that all configuration is safe.

A03: Software Supply Chain Failures

Review the dependencies declared in package.json, the resolved versions, and the tools used to build and distribute the app. A package suggestion can be outdated, mistaken, or unsafe regardless of how it was produced.

How It Shows Up in an App

Check the actual installed versions and provenance of packages such as lodash or express; the names alone do not establish a vulnerability. Supply-chain review also covers build tools, repository access, and artifact distribution.

The Fix: Dependency And Pipeline Review

Use the vulnerability-audit command appropriate to your package-manager version, such as npm audit or yarn audit in versions that support it. Investigate applicability, test updates, and monitor advisories. A clean dependency report does not prove that the build pipeline or every dependency is trustworthy.

A07: Authentication Failures

This covers weaknesses in how the app confirms a user's identity, including session management and password strength.

How It Shows Up in an App

Test password and recovery flows, session expiry, logout behavior, and MFA where required. Check whether protections still hold when requests are made outside the normal UI.

The Fix: Configure And Test Authentication

A maintained authentication service can provide useful controls, but you still need to configure and test the integration, recovery paths, and session handling. Authentication does not replace authorization checks.

A08: Software or Data Integrity Failures

Review whether code, updates, and trusted data can be changed without appropriate integrity checks. Include trust in external resources and the handling of untrusted serialized data.

How It Shows Up in an App

A third-party script can change independently of your app, and imported data may be treated as trusted without validation. Review the source and integrity requirements before including either in a privileged workflow.

The Fix: Integrity Controls

For compatible external script or stylesheet resources, SRI hashes let a browser check the fetched bytes against an expected digest. Review the expected source before generating the digest; a hash does not prove the code is benign. Protect CI/CD credentials and changes, and review lockfiles such as package-lock.json as part of dependency control.

A09: Security Logging and Alerting Failures

Plan which security events to record, who reviews them, and what should trigger an alert. Logs are useful only if the relevant events reach a protected destination and can be investigated.

How It Shows Up in an App

Missing or inaccessible authentication and authorization events can make incident investigation harder. A call such as logger.warn('Failed login attempt') illustrates an event message, but useful logging also needs context and a protected destination. Test logging on allowed, denied, and failed operations, and avoid storing secret credentials or unnecessary personal data.

The Fix: Test Observability

Collect relevant application events and test alert delivery. HTTP uptime monitoring can alert on configured availability failures through supported integrations, but it does not inspect all security events or guarantee instantaneous detection.

A10: Mishandling of Exceptional Conditions

Test timeouts, dependency failures, resource exhaustion, and partial operations. Authorization failures should not silently allow access, and retries should not duplicate sensitive mutations. Review cleanup, bounded retries, and safe error responses. See OWASP A10:2025.

Server-Side Request Forgery Within A01

SSRF occurs when an attacker can cause a server to make an unintended request. Review destinations influenced by untrusted input, including indirect paths through redirects or fetched metadata.

How It Shows Up in an App

URL imports, link previews, webhooks, and proxies deserve review when untrusted input can affect the server's destination. The feature name alone does not establish a vulnerability.

The Fix: Constrain Outbound Requests

Allow only the destinations and protocols needed by the feature. Check resolved addresses and every redirect, and use network restrictions where appropriate. A textual hostname check alone can miss private-address or DNS-rebinding paths.

The Emerging "Agentic" Risks (ASI)

The separate OWASP Top 10 for Agentic Applications covers risks in systems that take actions through tools. Examples include:

• Agent Goal Hijack: Untrusted instructions redirect an agent's intended objective.
• Tool Misuse: A tool is invoked in an unintended or unauthorized way.
• Identity and Privilege Abuse: Credentials or permissions allow actions outside the intended scope.

These are examples from a separate framework, not replacements for the web-app categories above.

Include Security Review In Delivery

Security and performance need their own measurements and tests. A fast app can have broken authorization, while a slow app is not necessarily vulnerable to the same issue.

Review controls as part of feature work, then verify the deployed result. Record gaps that remain outside your tests and automated coverage.

Use SimplyScan for supported public-resource checks without signup, subject to usage limits.

A URL scan can identify recognized secret patterns, returned-header issues, selected backend exposure signals, and supported performance signals. It does not cover the whole OWASP Top 10 or inspect every private RLS policy.

Review Checklist

Database

Are the backend's data permissions tested for allowed and denied operations, including RLS where applicable?

Auth

Are authentication, recovery, and session controls configured and tested, including MFA where required?

Inputs

Are inputs validated for each operation and handled safely by downstream interpreters and output contexts?

Secrets

Are secret credentials kept out of browser output and public files? If using .env files, are they excluded from public serving and version control?

Headers

Are browser policies appropriate for the app? Review X-Frame-Options and Content-Security-Policy, including their interaction and compatibility.

Monitoring

Do you have uptime alerts and security logging?

Review Priorities From The 2025 Categories

• A01: Access Control: Enforce backend permissions, including outbound-request restrictions where relevant.
• A05: Injection: Use safe parameter interfaces; an ORM alone is not a guarantee.
• A02: Misconfiguration: Review deployed settings and browser policies.
• A03: Software Supply Chain Failures: Use relevant tools such as npm audit, and review the build and distribution pipeline.
• A10: Exceptional Conditions: Test failure paths, cleanup, and safe denial.

Treat generated code as a draft that requires review and tests. A free scan can contribute findings within its scope; it does not certify an app against the OWASP Top 10.

FAQ

What is the OWASP Top 10?

The OWASP Top 10 is an awareness document describing major web-application security risk categories. This article follows OWASP Top 10:2025. It helps organize review, but it is not a complete test plan or a certification that an application is secure.

Which OWASP authorization risks should I check in generated code?

Review whether each protected operation checks the requester's permissions, including record ownership, roles, and legitimate sharing. Test signed-out users and different accounts. The aggregate scan corpus does not rank OWASP risks specifically within AI-generated apps.

Does using AI coding tools make my app less secure?

The development method alone does not establish how secure an app is. Review generated code, dependencies, and deployed settings, and test the authorization and failure behavior your app requires. A working feature is not evidence that those controls are correct.

Is npm audit enough to cover the OWASP Top 10?

No. npm audit reports supported known-vulnerability matches; it is not a full application test. Review access control, design, configuration, failure paths, and other relevant categories separately. SimplyScan also has bounded coverage and does not replace that review or the dependency checks provided by npm audit.

Do I need to worry about SSRF if my app never fetches user-supplied URLs?

Review whether untrusted data can influence any server-side destination, including redirects and indirect fetches. An app without such a path has less exposure to this attack mechanism, but confirm the behavior of integrations and dependencies rather than relying on feature labels. Inspect relevant fetch and axios calls and the destinations they can reach.

How can I test my app against the OWASP Top 10?

Use the categories to define a test plan for your app. Review source and configuration, test authenticated operations with different accounts, and exercise relevant failure paths. SimplyScan and its standalone tools can contribute supported findings, but do not establish complete coverage of the framework.

These live figures describe all scanned sites. They do not establish prevalence for an AI-built subgroup, compare development methods, or attribute findings to AI generation.

30% of the 119 live sites SimplyScan has scanned (36 sites) have at least one high or critical security issue.