Most founders do not discover this mistake from a security audit. They discover it from a Stripe email telling them something is wrong. By then, the damage is already done.
The mistake looks like working code
When you ask an AI tool to build a checkout flow, it generates something that works perfectly. Payments go through. The UI looks right. You ship it and move on.
What you do not see is that the AI quietly placed your Stripe secret key inside a page component, which means it shipped to every single visitor's browser the moment you deployed. Anyone who opened your site and looked at the page source could read your key, copy it, and use it.
No hacking required. No special skills. Just a browser.
What your Stripe secret key actually controls
This is the part most people underestimate. A Stripe secret key is not just access to your checkout flow. It is the master key to your entire Stripe account. Whoever holds it can do everything you can do:
- Issue refunds directly to any bank account they control
- Trigger payouts and move your balance out of Stripe
- Read the full payment history of every customer you have ever had
- Create, modify, or cancel any subscription on your account
- Charge any saved card on file
There is no secondary confirmation. No two-factor prompt. If someone has your secret key, they have your Stripe account. Full stop.
Why AI tools keep generating this vulnerability
AI coding assistants are optimized to produce code that works. They are not optimized to understand the security boundary between your server and your users' browsers. So when you ask for a checkout page, the AI reaches for the most direct path: grab the key from your environment variables and pass it into the component.
It looks completely normal. It passes every functional test. And it silently destroys the one security boundary that was protecting your revenue.
Your Stripe secret key was designed to live only on your server. The moment it touches a browser component, it is exposed.
The vulnerable pattern versus the secure one
Here is what the AI generates:
// page.tsx — runs in the browser — VULNERABLE
const stripeKey = process.env.STRIPE_SECRET_KEY;
export default function Checkout() {
return <PaymentForm secret={stripeKey} />;
}
Every visitor to this page receives your secret key inside the JavaScript bundle their browser downloads. It is sitting there in plain text.
Here is what it should look like:
// /api/checkout/route.ts — server only — SECURE
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);
export async function POST(req) {
const session = await stripe.checkout.sessions.create({...});
return Response.json({ url: session.url });
}
The key never leaves your server. Your users' browsers talk to your server, and your server talks to Stripe. The secret stays secret.
What actually happens when a key gets found
Exposed Stripe keys do not sit undiscovered. Automated bots constantly scan public websites and GitHub repositories looking for them. The window between a key being exposed and it being picked up can be minutes, not days.
When a key is found and abused, the sequence typically looks like this: a series of refunds are issued to accounts the attacker controls, subscription charges are cancelled to cause revenue loss, customer payment data is harvested, and payouts are triggered to move your balance out. Stripe will often suspend your account during investigation, which means your legitimate customers cannot check out while you sort it out.
The financial damage is real. The reputational damage with customers is worse. And depending on your jurisdiction and what customer data was accessed, you may have legal disclosure obligations on top of everything else.
How to find out if you are affected right now
Search your codebase for these patterns anywhere outside your API routes directory:
STRIPE_SECRET_KEYreferenced in a page or component file- A secret key being passed as a prop to any component
process.envappearing inside a file marked"use client"- Any secret key name prefixed with
NEXT_PUBLIC_
If you find any of these, treat your current key as compromised. Rotate it in your Stripe dashboard immediately, then fix the code so the new key never reaches the browser.
The bigger picture
This is not an edge case or a beginner mistake. It is what AI coding tools produce by default when asked to integrate Stripe. If you have built a payment flow with the help of an AI assistant and have not specifically audited where your secret key lives, there is a real chance it has been exposed at some point.
The engineers who ship this are not negligent. They trusted a tool that optimizes for working code, and security is a different axis entirely. That gap is what attackers exploit and what CodeHalo is built to close.
Run a free lite scan to find out if this vulnerability exists in your repo before someone else does.
FAQ
How would someone actually find my key? Is it that easy?
Yes. Your JavaScript bundle is downloaded by every browser that visits your site. Anyone can open DevTools, go to the Sources tab, and search the bundle files for common key patterns. Automated scanners do this at scale across millions of sites. If your key is in a client-side bundle, it is effectively public.
I built this months ago. Should I assume my key was found?
Treat any key that was ever in client-side code as compromised, regardless of how long ago it was deployed. Rotate it now. The cost of rotating a key is low. The cost of finding out it was already used against you is not.
Does this only affect Next.js?
No. Any framework that bundles environment variables into client-side JavaScript has this risk. The specific variable naming rules differ by framework, but the underlying danger is the same: a secret that reaches the browser is no longer a secret.
Will rotating my key immediately stop any ongoing abuse?
Yes. Revoking the old key cuts off anyone using it instantly. Do it first, then fix the code, then deploy a clean version.