Vibe Coding Security Tools: What Each Type Catches

AI-built apps fail in a particular pattern. The code compiles, the UI works, and the security decision was never made: nobody wrote the rule that limits who can read a table, or the check that ties an ID in a URL to the signed-in user. A tool can only report on what it can observe, and many of these failures are the absence of something.

So the useful question is not 'which tool is best?' but 'which layer does this tool see, and which failure lives in a layer it cannot see?'.

A secret scanner looks for credentials in files and in git history. Gitleaks is a widely used open source example: it uses patterns and entropy checks, can scan a repository's history, and can run as a pre-commit hook. GitHub offers a hosted equivalent that also blocks pushes containing recognized secrets.

It catches keys pasted into source, config files committed by accident and tokens left in old commits. It misses secrets that never touch git, such as a key that leaks through a build that bundles it into browser JavaScript, and it cannot tell you whether a leaked key was already used.

npm audit sends a description of your dependency tree to the registry and reports known vulnerabilities. It is the simplest gate to add, and its audit-level option lets you fail the build only above a chosen severity.

It catches known-vulnerable versions of packages you use. It misses flaws in your own code, packages that are malicious but not yet reported, and a package added under a slightly wrong name. AI assistants sometimes suggest packages that do not exist or are near-misses of popular ones, so read new entries in the lockfile diff.

Static analysis reads source code without running it. OWASP notes that these tools scale well and point to exact lines, but can automatically identify only a relatively small share of application security flaws, produce many false positives, and struggle with authentication and access control issues and with configuration that is not represented in code.

For an AI-built app that last point is decisive. A missing authorization check is code that is not there, so there is nothing to flag. Use SAST for injection patterns, unsafe functions and obvious mistakes, and do not read a clean report as a clean app.

Dynamic scanners probe a running site from outside. OWASP ZAP is a widely used open source example, and its baseline scan runs a short spider crawl and then passive checks without attacking, which its documentation describes as suitable even for production sites you own.

They catch missing headers, exposed cookies without secure flags, and some misconfigurations visible in responses. A passive baseline will not log in, will not try one user's ID against another's data, and will not find a table that only answers when asked with the right key. Run scanners only against systems you own or have written permission to test.

For apps that talk straight to a hosted database, the most valuable check is often the simplest: list every table in an exposed schema and confirm that access rules are on and correct. Supabase's documentation states that a table in an exposed schema without Row Level Security is readable and writable by any role with a grant on it, and that enabling RLS alone is not the whole job: you must also review grants and write policies for each operation.

Checkers here read your rules and, in the best case, test them by making real requests as an anonymous user and as a second user. They miss business logic, such as who is allowed to approve a refund.

Header checkers, including the browser's own network tab, verify HTTPS, Content-Security-Policy and similar response headers. CSP helps limit the damage of cross-site scripting by restricting what code a page may load, but it is a second line of defense, not a fix for unsafe code.

Human review is the only layer that reasons about intent: whether the rule itself is right. It is slow and costly, so spend it on the parts where a mistake is expensive, namely authentication, payments, and anything storing sensitive personal data.

Think in three tiers. Tier one runs on every push and costs nothing: secret scanning with push protection, a dependency audit and a linter. Tier two runs before each release: a passive runtime scan of your staging site, a review of every database table's rules, and a check of headers. Tier three is occasional: a human reviewer on authentication, payments and data handling, plus your own two-account test for cross-user access.

If you can only do one thing beyond tier one, do the two-account test. It is the one check that no automated category reliably replaces.