The real-browser pass
A headless Chromium walks your routes cold and through client navigation, and records every request the page makes.
Headers tell you what a server promises. A browser tells you what your application actually does. The browser stage is where most of the interesting findings come from, because it sees your app the way a user does.
What it records
- Routes, discovered and clustered so that the same page with different data is not scanned twenty times.
- Every request per route, on a cold load and again through in-app navigation.
- Third parties, their weight, and what your page sends them.
- JavaScript errors, failed requests, insecure form actions and WebSocket behaviour.
- Load, DOM-ready and time-to-first-byte per route, stored as baselines to measure regressions against.
Cold load versus client navigation
A single-page application misbehaves in ways a cold load never reveals: refetching everything on navigation, oversized payloads between views, request storms from one interaction. Both passes are recorded so the difference is visible.
The access-control probe
One check is active rather than passive. To prove a data API answers anyone, something has to ask it. The probe replays a request your own page already made, with the public key your own page already ships, a bounded number of times, and records only that the data was readable - never the data itself.
Questions
Will the browser pass slow down my site?
It walks a limited number of routes, rate-limited, with a scanner user agent, and backs off when a site is struggling. It behaves like one careful visitor, not like load.
Does it log in to my app?
No. Everything it does is available to an anonymous visitor. Authenticated crawling is not something the scanner does today.
Will it submit my forms or send emails?
No. Nothing is submitted, nothing is written, and no state-changing request is made.
Something here wrong, missing or out of date? Tell us and we will fix the page.