Put publishable keys in browser and mobile code, and keep secret and restricted keys on the server. Prefer restricted keys for server code, because they limit what a stolen key can do. Webhook signing secrets are separate from API keys and also stay private.
The three types
Stripe's API keys documentation lists the key types and whether each is safe to expose. A publishable key is meant for client libraries and mobile SDKs. It can identify the account and create tokens or payment methods from payment details, but it cannot perform other actions. A secret key has unrestricted permissions on all APIs, and because you cannot limit it, the documentation does not recommend secret keys for new use cases and suggests migrating existing secret key usage to restricted keys. A restricted key is limited to the permissions you choose.
Test and live keys are distinct, and the documentation shows a naming prefix for each type and mode. The page also states that webhook secrets are separate from API keys and are found under each webhook endpoint.
Placement table
| Key | Safe in client code? | Where it lives |
|---|---|---|
| Publishable | Yes | Browser, mobile app |
| Restricted | No | Server only, with narrow permissions |
| Secret | No | Server only, avoid for new work |
| Webhook signing secret | No | Server only |
Steps to tighten a store integration
- Inventory every key in use: storefront code, back office plugins, serverless functions, CI and hosting settings.
- Replace any secret key with a restricted key limited to the calls that service makes. A refund service does not need permission to create payouts.
- Remove hard coded keys from source. The platform documentation recommends removing hardcoded keys before using a live key in a back end application.
- Use one key per service, so a leak points to one place and rotation breaks one thing.
- Rotate on staff changes and after any suspected exposure.
What a restricted key buys you
If an attacker steals a restricted key from a plugin, they can do only what you granted. That turns a possible account wide incident into a bounded one. It is the same least privilege idea as limiting app scopes in a storefront admin.
Try it yourself
Click through it at your own pace, or open it full screen. Look for how a hard coded credential is reported and how a fix is suggested.
Safeguard can flag hard coded secrets in repositories, and you can start with the free scan at gold.safeguard.sh/scan.
Quick check
Is a publishable key a security problem if it is public?
No, it is designed for client code. Treat it as an identifier, not a credential that can move money.
Is a webhook secret the same as an API key?
No. The documentation describes webhook signing secrets as separate. Store it like any other secret.
Sources
Last reviewed: 19 October 2026.
