Commerce credential investigations
A payment key is visible on your site. Is it a secret?
The answer depends on the issuer and key type. Stripe publishable keys are designed for client-side use; secret and restricted keys belong on the server. Classify the key before deciding what to contain.
One issuer, different key types
Stripe documents these three key classes. The prefixes shown here are examples, not real credentials.
- pk_…
- Publishable. Stripe allows this key type in browser and mobile code. Its presence alone is not a secret leak.
- sk_…
- Secret. Keep it server-side. If exposed, contain it promptly at Stripe while preserving available evidence.
- rk_…
- Restricted. Also sensitive; its permissions depend on configuration. Contain exposure and confirm scope in Stripe.
This distinction is specific to Stripe. Check the issuing service’s documentation for any other key type.
Stripe API key documentationWhere commerce credentials turn up
Start with connected sources and external assets your organization monitors.
A pull request
A server-side payment key can be copied into repository code or configuration. Review the location and whether the change reached a public branch or deployment.
A shared file or message
A credential pasted into a connected document store or chat may have more readers than its issuer account. Identify copies and the service that uses it.
A public storefront asset
With content checks enabled, an external scan can examine bounded public HTML, JavaScript and JSON. A match needs key-type and issuer review before it becomes an incident conclusion.
From match to issuer action
Classify first; do not delay containment of an exposed sensitive key while investigating logs.
- 01
Classify the key
Identify its issuer, type, live or test environment, and source. A Stripe publishable key calls for a different response from a server-side secret.
- 02
Contain at the issuer
For an exposed sensitive key, the owner rotates or revokes it at the issuer and updates dependent services. Preserve the source and available logs without delaying containment.
- 03
Assess the remaining exposure
Use Cremit’s validity result for supported types. Review issuer permissions and request logs, look for other copies, and record the outcome. A match or live result alone does not prove misuse.
What the result cannot promise
Use the finding to start an investigation, then confirm account-specific facts at the issuer.
- Cremit scans connected code, cloud storage and collaboration sources, plus monitored external assets when enabled. It does not inspect every system or every copy of a key.
- Automatic validity checks apply to supported credential types. A checked key may change state later; a verification result does not prove whether it was misused.
- AWS access key and GCP API key permission analysis does not describe the permissions of a Stripe, Shopify or other commerce key. Review those permissions at the issuer.
- Cremit does not rotate or revoke issuer credentials, protect customer data by itself, or certify PCI DSS compliance.