Sandbox or test keys. Stripe's documentation separates sandbox keys, which start with sk_test_, from live keys, which start with sk_live_, and says secret keys must stay in your server environment. Developers should work with sandbox keys, and live keys should reach only the production service that needs them.
How the key types differ
Stripe's key documentation explains that every API request happens in either a sandbox or in live mode. Sandbox keys begin with pk_test_ for publishable keys, rk_test_ for restricted keys and sk_test_ for secret keys. Live keys begin with pk_live_, rk_live_ and sk_live_. The page tells you to create or select a sandbox for building and testing, and to switch to live keys when you are ready for real payments. For new integrations it suggests a separate general sandbox so settings and data remain isolated from live mode.
The same pattern exists in many other payment and API providers, though the names differ.
What the best practice page says
Unlike publishable keys, which are safe to include in webpages and apps, secret keys must stay in your server environment. The page advises using restricted API keys with limited permissions instead of unrestricted secret keys, and explains that restricted keys help limit the potential impact of a compromise. It also tells you not to put restricted or secret keys in your code, even code that stays on your servers.
If your platform does not provide a secrets vault, the guide says to supply keys to your application through environment variables, and notes that some platforms let you mark variables as sensitive so you cannot see them again after you set them.
A rule set for teams
| Where | Key allowed |
|---|---|
| Developer laptop | Sandbox keys only |
| Shared staging | Sandbox keys, separate from any individual's |
| Production service | Live restricted key, stored in the platform's secret store |
| Browser or mobile app | Publishable key only |
| Source code and chat | No keys at all |
Give each environment its own key, so a leak in development cannot touch live payments, and so you can rotate one without an outage elsewhere.
Reduce the damage of a mistake
Create restricted keys that allow only the calls a service makes. A reporting job that reads charges has no business holding a key that can issue refunds. Use the dashboard's key page to expire and rotate keys on a schedule, since the documentation says it lets you create, reveal, expire and rotate keys for the account or sandbox you are viewing.
Keep a short runbook for a leaked live key: who can revoke it, how to roll a replacement into production, and how to review recent activity.
Habits for local development
Load the sandbox key from an untracked file or your password manager at run time. Use fake card data supplied by the provider's test tools. Avoid copying production data into a sandbox, since that defeats the isolation. When a new teammate joins, create access for them rather than forwarding a key from someone else's machine.
Where Safeguard fits
Safeguard works on the dependency and code side of your software: SBOM and dependency scanning, reachability analysis and policy gates. It does not store or manage credentials, so keep using your password manager, secrets manager or cloud identity for that. You can run a free scan of a project at gold.safeguard.sh/scan.
Quick check
Can the publishable key go in a web page?
Stripe's documentation says publishable keys are safe to include in webpages and apps. Secret keys are not.
What do the key prefixes tell me?
Whether it is a publishable, restricted or secret key, and whether it belongs to a sandbox or live mode.
Do I need a secrets vault?
Stripe says to use one if your platform provides it, otherwise use environment variables.
Sources
Last reviewed: 19 October 2026.
