A production SaaS can look finished while still exposing the endpoint that lets one customer read another customer's records. That is the practical value of an OWASP ZAP scan for web application security: it gives you a fast view of how an attacker sees the live app, rather than how the code was intended to behave.

For founders shipping with AI-assisted code, hosted authentication and Supabase, that distinction matters. A scan may reveal missing browser protections, overly permissive CORS, insecure cookies or an endpoint returning more data than it should. It will not, by itself, prove that every account boundary and payment flow is safe. Used well, though, ZAP is an efficient first pass that points your security review towards the areas most likely to cause operational damage.

What OWASP ZAP checks in a live application

OWASP ZAP is a web application proxy and security scanner. It crawls pages, observes requests and responses, and tests for common weaknesses. In a normal workflow, it can spider public routes, inspect JavaScript-discovered paths and perform active checks against the endpoints it finds.

The output often includes issues such as missing Content Security Policy (CSP), absent HSTS, cookies without Secure or HttpOnly flags, reflected input handling, weak cache controls and server information disclosure. These are useful findings, but they vary sharply in severity. A missing header needs attention, yet it is not automatically equivalent to an exposed service-role key or an IDOR flaw that leaks every user's data.

That distinction is where many early-stage teams lose time. They receive a long scanner report, fix the first ten warnings, and assume the application is secure. The better question is: which findings create a credible path to data exposure, account compromise, fraud or unauthorised actions?

Start with safe scope and realistic access

Never aim an active scan at production without deciding what it may touch. ZAP can submit forms, follow links and send test payloads. On an app with payment actions, invitation flows, destructive admin controls or emails triggered by requests, careless scanning can create noise or affect real users.

Set a clear target scope first. Include the production domain and approved API hosts. Exclude logout routes, payment-provider endpoints, account deletion, webhooks, irreversible workflow actions and any third-party services. Use a dedicated test account with no real customer data, limited permissions and a mailbox your team controls.

Authentication is equally important. An unauthenticated scan only sees the public surface. That may be appropriate for a landing page or public API, but it will miss the routes where SaaS applications usually hold their highest-risk problems: dashboards, team workspaces, exports, billing settings and admin tools.

For authenticated coverage, configure ZAP to use a test session and verify that it remains logged in while crawling. If it silently falls back to the login page, the report may look clean simply because the scanner never reached the protected application. Check the session history, not just the final alert count.

Scan more than the browser UI

Modern applications often place their real logic behind APIs. A React or Next.js interface may show only a small number of pages while the browser calls dozens of REST, GraphQL or serverless endpoints. If ZAP only crawls the visible UI, its view will be incomplete.

Feed the scanner your API definition where one exists, such as an OpenAPI specification, and inspect browser traffic through the proxy during normal test-account use. This helps ZAP discover endpoints created dynamically by JavaScript. It also exposes the requests worth reviewing manually: calls that accept object IDs, change permissions, issue refunds, return user profiles or access stored files.

How to interpret OWASP ZAP scan findings

Treat the report as evidence to investigate, not a release verdict. Every alert should be assessed against the affected route, the application role required to reach it, the data involved and the impact if the issue is exploited.

A practical triage approach is to separate findings into four groups:

• Immediate exposure: leaked credentials, public database access, sensitive API responses, exploitable injection or routes allowing unauthorised access.

• High-impact control failures: broken authentication handling, insecure session settings, missing authorisation checks and unsafe payment or administrator actions.

• Hardening gaps: missing CSP, HSTS, X-Frame-Options or restrictive CORS settings, where the surrounding context determines urgency.

• Scanner noise or duplicates: alerts caused by development artefacts, intentionally public content or controls already enforced elsewhere.

The key is not to downgrade a finding because it is inconvenient. It is to establish what is actually reachable and what an attacker gains. For example, ZAP may report that an API response contains an internal identifier. That is not necessarily a vulnerability. But if changing that identifier returns another organisation's invoices, messages or files, you have an IDOR issue with a direct business impact.

Headers are necessary, but they are not the whole audit

Security headers are a common source of ZAP alerts because they are easy to detect. They deserve attention. HSTS helps prevent downgrade attacks, CSP reduces the impact of some cross-site scripting paths, and frame protections can reduce clickjacking risk.

However, headers cannot correct an API that trusts a client-supplied user ID, a Supabase table with row-level security disabled, or a backend endpoint that accepts an unsigned JWT. Prioritise access control and secrets first. Then tighten headers and browser policies as part of a deliberate baseline.

The blind spots founders should plan for

ZAP is particularly good at identifying known web patterns on reachable endpoints. It is less effective at understanding your business rules. That is not a flaw in the tool; it is a limit of automated scanning.

Consider a marketplace where a seller can update a listing. The request may return HTTP 200, use valid authentication and include no obvious injection issue. The serious question is whether Seller A can replace the listing ID with Seller B's ID and change it. A scanner cannot reliably determine the intended ownership model without testing multiple roles and understanding the workflow.

The same applies to Supabase row-level security. A live scan may identify that an endpoint returns data, but it cannot confirm that each policy correctly limits rows across tenants, roles and edge cases. Review the SQL policies, the client and server use of keys, and the way user identity reaches database queries. A public anon key is expected in many Supabase projects; a service-role key in a frontend bundle is not.

AI-generated code adds another reason to validate manually. It can produce endpoints that function correctly in happy-path tests while skipping an authorisation check on a less-used action. It can place secrets in environment examples, logs or client-side configuration. Automated tools may flag clues, but repository review is what connects them to the actual deployment path.

A practical workflow for an OWASP ZAP scan for web application risk

Run a passive scan early, ideally against a staging environment that closely matches production. Passive scanning observes traffic without actively attacking the target, making it a sensible way to catch configuration gaps during development.

Next, use an authenticated crawl with a tightly scoped test account. Confirm which routes, APIs and roles were reached. Only then consider active scanning, preferably in staging first. Production active scans can be justified for a mature, controlled application, but they need exclusions, monitoring and a rollback plan.

When alerts arrive, avoid assigning fixes solely from the alert name. Record the exact URL, request method, affected parameter or response header, evidence from the scan, severity in your environment, owner and remediation status. For code issues, attach the relevant file path and line range. For configuration issues, identify whether the change belongs in the application, reverse proxy, hosting platform, authentication provider or database policy.

Retest after each meaningful fix. A CSP header might be present but too permissive. An endpoint may reject an unauthorised request in one route but still leak the same record through an export API. Retesting confirms the control works where it matters.

Pair the scanner with targeted manual review

A credible application-security assessment combines ZAP with repository scanning and human testing. Secret detection can locate exposed tokens. Dependency analysis can identify known vulnerable packages. Static analysis can surface dangerous data flows. Manual review tests the assumptions those tools cannot: tenant isolation, privileged actions, payment state transitions, JWT validation, Supabase RLS and whether server-side controls match what the frontend implies.

For a founder, the useful deliverable is not a 200-line list of alerts. It is a severity-rated set of findings that explains what is exposed, how it could be abused, where the fix belongs and what should be done first. HollowByte uses automated coverage including OWASP ZAP alongside manual review because a clean scanner output is not the same thing as a safe application.

Run ZAP before the next launch, investor demo or customer rollout - but give its findings the scrutiny they deserve. The scan tells you where to look. The work that protects the business is verifying the real exposure and closing it properly.