A passive scanner.
No login. No writes.
vybckr looks at exactly what an attacker sees on day one — your public surface. We never log in, never POST data, never touch a database we do not already have public credentials for. Same threat model as someone opening DevTools.
Six stages, in order.
A scan typically completes in twenty to forty seconds. Each stage runs only if the previous returned data worth looking at.
- I.
Bundle inspection
We fetch your HTML and pull every JS chunk it references. Each chunk is regex-scanned for fifty-plus secret patterns: AWS keys, Stripe keys, OpenAI keys, JWTs, GitHub tokens, Supabase service-role JWTs, Firebase config, and more. Source maps, if present, are parsed.
- II.
Header sweep
Security headers (CSP, X-Frame-Options, Strict-Transport-Security, Permissions-Policy, Cross-Origin-*), cookie flags, CORS configuration, and server fingerprints. One round-trip; no authentication.
- III.
Common-file probes
We check well-known paths: /.env, /.git/config, /config.json, /admin, source maps, /robots.txt, /security.txt. We never bruteforce — only canonical paths a careful operator already expects to be queried.
- IV.
Vendor fingerprinting
When a vendor signature surfaces in the bundle (Supabase URL, Firebase config, Clerk pubkey, Convex deployment URL, Neon connection string, Vercel headers), we run vendor-specific deep checks against that vendor's public API only.
- V.
Vendor probes, read-only
Supabase: try reading common tables and the OpenAPI schema dump with the leaked anon key. Firebase: probe Firestore rules with no-auth reads. Clerk: inspect public configuration. Convex and Neon: surface enumeration. All read-only. An RLS denial is a silent pass — that is the system working correctly.
- VI.
Grade and report
Findings are weighted by severity and confidence. The grade is a rollup, not a marketing letter — an F means a critical-confidence-high was found. Each finding ships with plain-English impact and a one-paragraph fix.
What we do not do.
Honesty earns trust. The following list is what vybckr does not catch — by design or by limitation.
- 01Logic bugs and business-rule flaws. Those need a human reading your code.
- 02Authenticated attack surface — anything behind login. Quick Scan is unauthenticated only.
- 03SQL injection, XSS, CSRF. Mostly mitigated by modern frameworks; explicit dynamic testing is not our scope.
- 04Dependency vulnerabilities. Use Snyk or Dependabot for that.
- 05Social engineering, phishing surface, credential leaks on the dark web.
- 06Anything that requires breaking the law to verify.