Security news
AI-built sites exposed private keys. Check every copy of your app.
Vibe App Scanner ·
Cyble reports that 35 of the 22,306 websites it classified as AI-built exposed private credentials in public frontend code. If you build apps with AI, the useful response is to inspect what your own deployment ships, identify the permissions behind each key, and check every copied project that uses it. The finding does not establish that your app is affected. Cyble's original research.
One copied project can repeat the same exposure
The October 22 report describes a Slack webhook repeated across 13 similar domains and a Stripe secret key reused across four domains. That makes a deployment inventory part of the response: fixing the project you remember editing can leave a second copy serving the same credential. These are Cyble's reported observations; VAS has not independently tested those sites. Research and examples.
Start a small inventory of your own projects. Include the production domain, preview URLs, staging, and any copied starter project that is still deployed. For each entry, record the owner, deployment ID, and whether it uses the same backend or integration account. Keep credential values out of the inventory.
Identify what each visible key permits
A key-shaped string is a reason to classify the value. It is not a complete finding by itself.
| Value you find | Question to resolve | Next check |
|---|---|---|
| Supabase publishable key or legacy anon key | Is this the intended browser credential? | Review table permissions and RLS for the signed-out and signed-in roles |
| Supabase secret key or legacy service-role credential | Has a privileged backend credential reached a public artifact? | Identify its owner and begin the provider's exposure response |
| Another provider's API key or integration webhook | What operations and resources does this exact credential authorize? | Consult that provider's key documentation and account settings |
Supabase distinguishes browser-facing publishable keys from elevated secret keys. Secret keys bypass RLS; legacy service-role credentials are also elevated. The presence of a publishable key does not establish that the database permissions are correct. Supabase's key types and permissions.
Our Supabase RLS guide covers the access-policy side of that distinction.
Inspect the deployed frontend and its configuration
For each deployment you own:
- Open the application in a signed-out browser session and inspect the JavaScript resources it downloads. Work with your own app and test accounts.
- Compare configuration references with the credential inventory. Record the file or request location and a masked identifier. Do not paste full secrets into a ticket, chat, or coding-assistant prompt.
- Check how each frontend value entered the build. For Vite projects, variables prefixed with
VITE_are exposed in bundled client code. Use a controlled backend for operations requiring private credentials. Vite's environment-variable documentation. - Repeat the check for the other deployed copies in your inventory. A source-code change still needs to reach each intended deployment.
The existing Vercel security guide provides related checks for public configuration and preview deployments.
Close credential exposure in three separate places
If you confirm that a private credential was public, follow the issuer's current incident instructions. OWASP recommends revoking potentially compromised secrets. Removing a string from the application does not perform that provider-side action. OWASP secrets management guidance.
Use this editorial checklist to track closure:
| Workstream | Evidence to retain |
|---|---|
| Credential issuer | Revocation or rotation result, masked key identifier, responsible owner, and time |
| Every consuming deployment | Replacement configuration, deployment ID, and a successful intended operation |
| Every public artifact checked | The locations inspected, their deployment versions, and the result after remediation |
| Historical activity | Provider logs reviewed, time range, findings, and gaps in available history |
Coordinate the order with the credential owner and provider guidance. Record an unresolved item explicitly rather than treating a successful page load as completion of every workstream.
What this report cannot tell you about your app
Cyble's classified sample does not establish the rate of exposure across all AI-built applications. The report also does not isolate whether an AI assistant, a developer, or a later configuration change introduced each finding. We have not independently confirmed whether the reported credentials remain usable today.
Your own artifact inspection has limits too. It describes what you checked at a particular deployment and time. It does not establish whether someone previously used a credential, whether other application paths are vulnerable, or whether every copy was found.
For broader checks, use the vibe coding security checklist. You can also start a VAS scan as one part of reviewing your app. A scanner result cannot by itself reconstruct credential misuse or prove that incident recovery is complete.