Vibe coding security check
Is your app leaking a key to every visitor?
Paste the URL of a deployed app. In ten seconds Forge reads exactly what a stranger’s browser downloads and counts the two leaks that take generated apps down — a database service-role key or a provider API key shipped in the bundle — plus transport, headers and source maps. No account, nothing stored, nothing probed.
Try one:
The read is the same whichever tool built it:LovableBoltv0ReplitBase44CursorClaude CodeWindsurf
The five checks
What a visitor’s browser can tell you.
Each is a count over what was actually read, with the script it was found in. Severity is a fixed property of the finding type — a service-role key is urgent in every app — and the read says which checks could not run rather than reporting them clean.
- urgent
A Supabase service-role key in the bundle
A JWT whose payload says role "service_role" in any script the page ships — every visitor holds the key to the whole database, and row-level security no longer applies to them. Decided by the claim inside the token, never by the shape of the string, so the anon key is never a finding.
bundle-service-role-key
- urgent
A provider API key shipped to the browser
An OpenAI, Anthropic, Stripe live, AWS, GitHub or similar credential inlined by the bundler — a string literal, because a real inlined key is always quoted. The same placeholder gate the code read uses, so a documented example key does not count.
bundle-provider-secret
- high
Served over plain http
The page still answers over http after redirects. Everything a visitor types travels readable.
insecure-transport
- medium
Missing security headers
Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, a frame policy and, over https, HSTS — counted per header, so one mistake never reads as two.
missing-security-headers
- low
Public source maps
A source map the shipped scripts name that actually answers — your original source, downloadable by anyone. Only maps that answer count.
bundle-source-maps
Third-party scripts — analytics vendors’ bundles — are counted and skipped: they are not yours. Server-side code is invisible to this read by design; a key that never reaches the browser cannot appear here, and one that does is the finding. The method is published at forge.ambera.app/methodology.
Then fix it where the code lives
The fix arrives as a pull request.
Connect the repository and the same finding is read from the source — the secret behind the public prefix, the table without row-level security, the committed .env — and fixed on a branch in your own repository. Never a push to main; you review and merge. Deterministic fixes are free.
Not deployed yet? npx @ambera/review-tax read counts the source side of the same leaks on your own machine — nothing is uploaded. The Claude Code plugin runs it when a turn ends.
- Does it work on an app built with Lovable, Bolt, v0, Replit or Claude Code?
- Yes — on any deployed URL. The check reads what a visitor’s browser receives: the page, its same-origin scripts, its inline blocks, its headers and the source maps the scripts name. It never asks which tool generated the code, so the read is identical whichever one did.
- Is the Supabase anon key a security problem?
- No. The anon key is designed to sit in a browser and is never a finding. The leak that takes apps down is the service-role key — a token whose payload says role "service_role" — because it bypasses every row-level-security policy. Forge decides by that claim, not by pattern-matching a long string.
- What happens to my URL and my code?
- Nothing is stored. The check requests only what the page hands out — no guessed paths, no API probing, no login — and refuses private addresses before it sends a request. Findings carry the script path and a count; a credential value never leaves the read. It is rate-limited like every free read.
- My app is not deployed yet. Can I check the source?
- Run npx @ambera/review-tax read in the repository. It walks the files git tracks on your own machine and counts the source side of the same leaks — a variable behind NEXT_PUBLIC_, VITE_ or EXPO_PUBLIC_ whose name says service role or secret, a credential written into the code, a table created without row-level security — and uploads nothing. No account.
- It found a key. What do I do?
- Rotate it first — the bundle is cached where you cannot reach it, so removing the key from the code is not enough. Then connect the repository and Forge opens the fix as a pull request on a branch, never a push to main: a committed .env is deleted and refused by .gitignore, exposed tables get one migration enabling row-level security. You review and merge.
- Can it see whether my database tables are protected?
- Not from outside — row-level security lives in your migrations, and the launch check deliberately probes nothing. Connecting the repository (or running the CLI) reads the migrations for tables created without an enable statement, and says plainly that RLS switched on in a dashboard is invisible to a read of the source.