A growing number of AI-built websites are going live with their most sensitive credentials visible to anyone who opens the page. New research from Cyble Research and Intelligence Labs (CRIL) found live OpenAI keys, Stripe secret keys and backend database tokens sitting in the public front-end code of sites created with AI app builders.
Over one month, CRIL scanned more than 1.3 million newly registered domains. Researchers used their own classifiers to identify sites generated by AI builders, then scanned their public code for credentials. Of the 22,306 AI-built sites identified, 35 exposed a genuinely private secret in the browser.
Why the Number Is Small, but the Risk Is Not
Thirty-five sites may sound minor. Cyble says the count is deliberately strict. Most key-shaped strings found on these sites are meant to be public. A single reCAPTCHA key, for example, appeared on thousands of sites.
The researchers filtered out values that are safe in a browser. These included browser-safe keys on 3,824 sites, Google API keys on 2,172 sites (a risk only if unrestricted), and Supabase or Firebase backend addresses on 1,461 sites (a risk only if backend rules are open). What remained were credentials that should never leave a server.
Each of those 35 hits, Cyble notes, is a live account an attacker can reach simply by viewing the page.
How AI-Built Websites Expose OpenAI API Keys
The most direct pattern involves sites that generate content using a large language model. On these sites, the key to that model often ships inside the code the visitor downloads.
Five sites carried live OpenAI API keys in client-side code, with 16 distinct keys between them. One AI-writing site shipped 12 separate OpenAI keys, one for each content category, stored as plain values in its JavaScript bundle.
An OpenAI secret key works as a billing credential. Anyone who reads it can spend the owner’s balance, exhaust the rate limit or run up the bill until the key is revoked.
Clone-and-Leak: One Secret, Many Domains
AI builders make the hundredth site as cheap as the first. Operators often clone a working template across many domains, and any secret in that template is copied to every site.
Cyble observed this in two cases. Thirteen near-identical domains, each pairing a short word such as “hello,” “chat” or “join” with one brand, served the same bundle containing the same live Slack webhook URL. Anyone reading the page could post messages into the operator’s Slack workspace, opening the door to spam, channel flooding or phishing aimed at the operator’s own staff.
In the second case, one Stripe secret key appeared on four domains under two different brand names. A Stripe secret key gives full API access to the account, including creating charges, issuing refunds and reading customer and payout records.
The Slack fleet ran on Bubble, a no-code and AI app builder, where values placed in client-accessible fields are shipped in plain text inside the app’s bundle. The Stripe cluster ran on a Next.js build. According to Cyble, this shows the problem spans builders rather than tracing to a single platform.
The Highest-Impact Exposure on AI-Built Websites
Four sites exposed a Supabase service role token on their front ends. Cyble ranks this as the most severe finding. The token bypasses row-level security and grants full read and write access to the project database, allowing an attacker to steal user records, alter or delete data, or plant content the app serves to its own visitors.
Across all 35 sites, the confirmed exposed API keys broke down as follows:
| Exposure | Sites |
|---|---|
| Slack webhook (shared) | 13 |
| Stripe secret key | 6 |
| OpenAI API key | 5 |
| AWS access key | 5 |
| Supabase service role token | 4 |
| GitHub token or Google OAuth secret | 2 |
Some sites appear in more than one category. Exposed AWS keys could allow cloud access, with crypto-mining often the first move, according to the research. GitHub tokens or OAuth secrets could enable access to source code or identity integrations.
When a key sits on a cloned fleet, Cyble warns, an attacker who finds it on one site has effectively compromised them all.
How to Stop the Leaks
Cyble’s recommendations for developers and AI builder users include:
- Keep secret keys in server-side functions or backend workflows, never in client-accessible fields.
- Use only publishable and anon keys on the front end, backed by row-level security, Firebase rules and API key restrictions.
- Rotate any key that has ever been exposed client-side and treat it as compromised.
- Search your own page source for strings such as sk-, sk_live_, service_role and hooks.slack.com before publishing.
For security teams, Cyble advises monitoring public code and newly registered domains for their own keys and webhooks. If a secret appears on one domain in a template fleet, the response should cover the entire fleet.
