Stripe Says Publishable Keys Are Safe to Expose. They're Not.

Stripe's own documentation states that publishable API keys are "meant solely to identify your account with Stripe, they aren't secret." The implication is clear: it's safe to expose them in your frontend code.

That's not the whole story.

Check Your Checkout Page

Use the tool below to scan your checkout page for exposed API keys. While Stripe publishable keys are designed to be in frontend code, you should be aware of what's exposed - and ensure you're not accidentally leaking secret keys.

The Attack

Attackers are scraping pk_live_ keys from websites and using them to validate stolen credit card numbers. Here's how it works:

1. Attacker finds any exposed pk_live_ key (yours, or anyone's)
2. They use Stripe's API directly to create Setup Intents or Payment Intents
3. They confirm those intents with stolen card numbers
4. Stripe's response tells them exactly what they need to know: card invalid, card expired, card stolen/blocked, or success (card is valid and sellable)

The attacker never touches your website. They're hitting Stripe's API directly with your publishable key. Your account logs the attempts, your fraud score takes the hit, and the attacker walks away with a list of verified "good" cards to use elsewhere.

Stripe's Response

When we reported this to Stripe, their response was telling:

"It looks like the card testers were obtaining client secrets for Setup and/or Payment Intents, then confirming the Intent with stolen card information... We recommend you make it more difficult for card testers to obtain client secrets."

Their recommended mitigations? Implement CAPTCHA. Add rate limiting. Use Stripe Radar (which costs extra).

The problem: the attacker isn't using your frontend. They're calling Stripe's API directly. CAPTCHA on your checkout page does nothing when the attacker never visits your checkout page.

The Documentation Gap

Stripe's documentation on publishable keys doesn't mention:

• That pk_ keys can be used for card validation attacks
• That attackers can confirm Payment/Setup Intents directly via API
• That your account bears the consequences of abuse you can't prevent

Their card testing documentation focuses entirely on frontend mitigations that don't address this attack vector.

What Stripe Could Do

This is an API design problem that Stripe could fix:

• Strict origin/referer validation on pk_ authenticated requests
• Aggressive rate limiting per publishable key
• Requiring a server-side signed token to confirm intents
• Anomaly detection for unusual intent confirmation patterns

Instead, they externalize the problem to merchants while their documentation says publishable keys are safe to expose.

The Bottom Line

Stripe's publishable keys aren't as safe as their documentation implies. If you're a merchant using Stripe, understand that your pk_live_ key can be used by attackers to validate stolen cards - and Stripe will tell you it's your problem to solve.

The real fix needs to come from Stripe. Until then, monitor your logs for unusual 402 patterns and be aware that "publishable" doesn't mean "safe."