Website vulnerability scanner: what it checks and what it misses on AI-built apps

What a website vulnerability scanner does

A website vulnerability scanner is a program that visits your site from the outside and compares what it finds with a list of known weaknesses. It does not read your source code or your database: it judges your site by the responses it gets back.

Most scanners work in three steps. They crawl: follow links, and on modern tools also the routes your JavaScript creates, to build a map of URLs and forms. They fingerprint: guess the server, framework and library versions from response headers, file names and code. Then they match: compare each version and each response with databases of CVEs (public, numbered vulnerabilities) and known bad configurations.

The checks come in two kinds, and the difference decides where you may run them.

What a scanner finds well

Scanners are at their best on problems that look the same on every website. A scan finds these in minutes:

• Missing or weak security headers. No Content-Security-Policy, no Strict-Transport-Security, pages any site can frame, a Referrer-Policy that leaks full URLs. The security headers guide gives the line to add for each.
• Cookie flags. A session cookie without Secure, HttpOnly or SameSite shows up in the first response.
• HTTPS problems. Plain HTTP that never redirects to HTTPS, redirects in the wrong order for HSTS, certificate issues.
• Outdated software. A Server: nginx/1.18.0 header, a script file with its version in the name, an old CMS plugin.
• Files that should not be public. An .env file, a .git folder, a database backup, a directory listing, source maps that publish your original code. See exposed .env files.
• Malware and blocklisting. Injected scripts, defacements, a domain flagged on a blocklist.
• Classic injection, with an active scan. SQL injection and cross-site scripting in forms and URL parameters are what active scanners were built for.

What a scanner misses on apps built with Lovable, Bolt, v0 or Cursor

Apps generated by AI tools are often built differently from the sites scanners were designed for: the browser talks straight to Supabase or Firebase, at an address like your-project.supabase.co, with a public key that ships in your JavaScript. Who may read which row is decided there, by row level security (RLS) policies or Firebase security rules.

A scanner pointed at yourapp.com tests yourapp.com. On a single-page app it may find little more than an HTML shell and a script file, then report a clean result while the database answers anyone who sends the right query. With no account, it cannot tell what a stranger who signs up can do either. Five leaks a scan of your domain does not test:

Free and open-source scanners people use

There is no single best website vulnerability scanner. Pick by what you want to learn (your header grade, malware, injectable forms) and by where it runs: an online scanner takes a URL, a tool you run yourself fits CI and staging, and only some can log in to test pages behind sign-in. Each option below is described from its own documentation.

Credit where it is due: ZAP's baseline scan and Observatory together cover most of a header and configuration review, at no cost, and paid tiers such as Pentest-Tools' Deep scan add authenticated scans and an IDOR check.

Run a passive scan on your own site

ZAP's baseline scan is a good first scan: passive, a few minutes, and it runs anywhere Docker does. Add -j --client-spider so the crawler also finds the routes your JavaScript creates. ZAP now recommends its client spider over the older Ajax spider for modern web apps.

docker run -v "$(pwd)":/zap/wrk/:rw -t ghcr.io/zaproxy/zaproxy:stable \
  zap-baseline.py -t https://your-app.example.com \
  -j --client-spider -r zap-report.html

How to read a scan result

A scan report is a list of maybes. Ask three questions of each line before you fix anything, or before you relax.

Is it real? False positives

Scanners match patterns, and patterns misfire: a search box flagged for a missing anti-CSRF token, a header reported missing on a redirect page. Reproduce first: open the URL, read the actual response, confirm the header or the file is really there. Once you have judged a rule, ZAP's config file lets you set it to IGNORE, WARN or FAIL, so known noise stops coming back.

Is the version real? Banner guesses

A finding like "this server version is affected by a CVE" often rests on nothing more than the version in a header. Red Hat explains that it backports security fixes into older versions, so the number stays old while the flaw is fixed, and that tools judging only by the version number produce false positives. The reverse holds too: a server that hides its banner gets no warning at all. For your own dependencies, trust the lockfile over the banner: enter the Next.js and React versions it pins in the Next.js CVE checker.

Can a stranger reach it? Severity vs reachability

Severity says how bad a flaw would be. Reachability says whether anyone can trigger it on your site. A critical CVE in a library that never sees user input can wait behind a medium finding on your login form. A missing header is a missing safeguard, not an open door.

Then the opposite trap, a clean report. Asked whether an A+ grade means a site is secure, Mozilla's FAQ answers that there are many security considerations it cannot test. A clean scan covers only what the scanner could see.

Only scan a site you own

Run a scanner only on a site you own or have written permission to test. ZAP's documentation is blunt about active scans: they are an attack on the target, and you should not use them on applications you do not own.

Even on your own app, an active scan has side effects, because it does what one careless user would do, thousands of times:

• It creates data. It submits the forms it finds: sign-ups, contact forms, comments, checkouts. Expect junk rows in your database and emails sent through your email provider.
• It trips limits. Thousands of requests in minutes can hit rate limits, bot protection and API quotas, and get your own IP address blocked.
• It costs money. Calls to AI routes, paid APIs and serverless functions are billed. A scanner that fuzzes an open /api/chat spends your credits.

So keep passive scans for production, run active scans on a staging copy with test data, and tag the traffic so you recognize it in your logs: ZAP's Replacer add-on can add a request header of your choice.

A scan routine for an app built with AI tools

A scanner covers the first and last lines. The rest depends on how your app stores data:

• Passive header and configuration scan on production, after each deploy that touches hosting or middleware.
• Supabase Security Advisor, or a read of your Firebase rules, after every schema change.
• Built JavaScript searched for server keys before each release.
• A two-account test on every page that loads a record by ID.
• AI routes called while signed out: they should refuse.
• An active scan on staging, with test data, after large changes.

The vibe coding security checklist goes through each item for Lovable, Bolt, v0 and Cursor apps.

Is a scan enough?

For headers, versions, exposed files and known CVEs, a regular passive scan plus an occasional active scan on staging covers a lot. For an app whose data lives in Supabase or Firebase, it is not enough, because the questions that matter are about identity: what someone signed out can read, whether user B can open user A's records. Each needs an attack, run as several identities, that either works or fails. The pentest vs vulnerability scan guide compares the two approaches.

That is the part Keybrum automates, on apps whose owner proved ownership. It tries your Supabase tables, RPC functions, storage and realtime channels and your Firebase rules, checks with two accounts whether one can read the other's records, calls AI routes without a session, and looks for secrets in the bundle and exposed .env files: more than 100 attacks in all. Each finding comes with the request that worked, your coding agent reads the fix through MCP, and plans attack again on every deploy. The automated penetration testing guide explains how that differs from a manual test.