Questions, answered straight.

No. Paste a public URL and you get the full report, no login, no repo access, no card. Accounts only start to matter once you want scan history, private reports, or CI.

No. Everything in the free scan works from the outside, which is the same view an attacker has of your app. The repo scan is a separate tool you run locally or in CI; it reads your filesystem and uploads nothing.

Any stack. Secret, route and header checks are stack-independent. Database-exposure checks currently cover Supabase and Firebase, with more backends on the way. The React Server Component leak check is Next.js-specific, because that's where the flight payload exists.

Usually under a minute. Flare.ai fetches your page and its bundles, probes reachable endpoints, checks DNS, and verifies any credentials it finds, all in parallel.

Yes. Every check is read-only against endpoints your app already exposes to the public internet. Flare.ai doesn't log in, modify data, or send attack payloads. It isn't a substitute for a full security review, but it's a strong first line.

Only to the company that issued them, and nowhere else. When we find a key in your bundle we make one read-only “who am I” request to that provider, whether that's OpenAI, Stripe or GitHub, to see whether it still authenticates. No model calls, no writes, no billable usage. That single request is what lets us say “this key is live, rotate it now” instead of “this looks like it might be a key”. You can turn it off entirely with FLARE_DISABLE_SECRET_VERIFICATION=1.

Very little. It's a page fetch, its JavaScript bundles, and a bounded set of small requests to candidate API paths, all with timeouts and a concurrency cap. It's comparable to a single visitor loading your site a few times.

Technically the checks are read-only and only touch public endpoints, but you should have permission before scanning something that isn't yours. Scan your own apps and client work you're authorised to test.

That's the thing we optimise hardest against. Keys are graded on whether they actually still work, not on pattern alone, so a credential you rotated months ago is reported as revoked rather than critical. Shadow-route probing sends a random control path first and stays quiet on apps that answer 200 to everything. Variables that are meant to be public, like Supabase anon keys and Firebase config, are allowlisted rather than flagged. A scanner you stop believing is worse than no scanner.

That we sent the credential to its issuer and the issuer accepted it. Not that it matched a regex, that it works. Findings are graded live, revoked, or unverified, and unverified is stated plainly rather than being dressed up as a maybe.

Because no safe read-only way exists to check them. An AWS access key ID can't be verified without the paired secret, which we don't have and don't want. Rather than guess, we say so and grade on format alone.

No tool does. Flare.ai catches the high-frequency, high-impact exposures AI-generated apps ship, the things a senior engineer would flag in a five-minute review. It's a floor, not a ceiling.

Yes, that's what the MCP server is for. Cursor, Claude Code and Windsurf can call Flare.ai directly, including against localhost, so the agent scans the dev server it just started, fixes what it finds, and rescans before anything is committed.

Yes. The deep scan ships as a CLI with exit codes, so a critical finding fails the build. There's a GitHub Action wrapper for the common case.

Rescan to confirm. On the free tier each website gets one scan, so rescanning is a Pro feature, that fix-and-confirm loop is the part teams use daily.