- Cyble found live private keys in the browser code of 35 of the 22,306 AI-built sites it identified. It describes two cases where a leak was cloned across a fleet of domains.
- On a cloned fleet, one leaked key is live on every copy, so one find exposes the whole fleet. Cyble calls the 35 a small number.
- Search your own page source for secret-key patterns, keep secrets on the server, rotate any key that was ever exposed, and watch for your keys elsewhere.
When copying is free, so is the mistake
An AI site builder makes the hundredth website as cheap as the first. That is the point of the tool. It is also the risk. Whatever flaw sits in the first site is copied to every clone.
Cyble Research and Intelligence Labs has put numbers on this. Its team spent a month checking more than 1.3 million freshly registered domain names. They picked out 22,306 sites made with AI app-builders and read each one's public front-end code. On 35 of those sites, a private secret was readable in the browser.
What Cyble found
The secrets were live. Cyble lists OpenAI keys, Stripe secret keys and backend database tokens. Five sites carried live OpenAI keys, sixteen distinct keys in total. One AI-writing site embedded a separate OpenAI key for each of twelve content categories, all readable in its code.
Four sites exposed a Supabase service-role token. Cyble says this kind of token bypasses row-level security, the rules that decide who can see which data. It grants full read and write access to the project database. Cyble ranks it at the top of the set by impact, because it opens the entire backend rather than a single service.
Cyble also found two cloned fleets. Thirteen near-identical domains all served the same live Slack incoming-webhook URL. Separately, one live Stripe secret key was reused on four domains that trade under two different brand names.
How a key ends up in the browser
A website sends its code to every visitor. Anything placed in that code can be read by anyone who opens the page. Some keys are designed for this, such as a reCAPTCHA site key or a Stripe publishable key. Secret keys are not.
Cyble traced the thirteen Slack-webhook domains to Bubble, a builder that lets people make apps without coding. It relied on a response header called x-bubble-perf and on markers in the page code. Bubble packages each app into a file named dynamic.js. Anything a developer enters in a field the browser can reach is written into that file as readable text.
The Stripe cluster ran on a Next.js build instead. Cyble says this shows the pattern spans builders and does not trace to one platform.
Why a fleet turns one leak into thirteen
The lesson here is about scale. A human developer who pastes a key into the wrong file makes one mistake. An operator who clones a working template makes it on every copy.
Cyble puts it plainly: a leak on a cloned fleet is live on every domain. Finding the key once unlocks the whole fleet. Cyble says a Stripe secret key gives full API access to the account, including charges, refunds, and customer and payout records. In the four-domain cluster, that one key exposes the same payment account on every site.
The Slack webhook is a smaller case. Cyble says it lets an outsider post into the operator's Slack as if from inside. The real risk it names is phishing aimed at the operator's own staff.
What the numbers do and do not show
The count is low, and Cyble says so. Millions of domains are registered every month, and this study covered 1.3 million over one month. The 35 is also what was left after heavy filtering. Cyble set aside 3,824 sites with browser-safe values, 2,172 with Google API keys, and 1,461 exposing a Supabase or Firebase backend address. Cyble says the last two matter only if the key is unrestricted or the backend's rules are open.
There are limits. Cyble built its own classifiers to spot AI-built sites. Four of the five sites with OpenAI keys are confirmed AI-generated. The report does not compare leak rates with hand-built sites. It does not show that AI builders cause more leaks than human developers. It shows that cloning spreads a leak, and that the leaked keys are live.
Cyble also sells threat-intelligence products. The findings are its own and have not been independently verified here.
Questions to put to your team
Cyble's advice is practical. Ask your teams these questions.
First, does any site we or our agencies publish, including AI-built marketing sites, carry a secret key in client-side code? Cyble's test is simple: open the page source and look for four strings. They are sk-, sk_live_, service_role and hooks.slack.com. Between them they mark OpenAI-style secret keys, Stripe live secret keys, Supabase service-role tokens and Slack webhooks.
Second, are secret keys held in server-side functions or backend workflows, with only publishable and anon keys in the browser? Do the database access rules and key restrictions actually apply, whether in Supabase, Firebase or the API provider?
Third, has every key that ever sat on the client side been rotated and treated as compromised?
Fourth, is anyone watching public code and new domain registrations for our own keys and webhook addresses? Cyble says to scope any response to the whole fleet, not one domain.
Cyble's own warning is short: if you can find a key in your page source, so can anyone else.
WebPulse's conclusion is that when publishing is free, checking becomes the only step that still costs anything.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Cyble.
