Leaked Stripe restricted key — scoped damage, still rotate

Stripe restricted keys (rk_live_*) grant limited scopes rather than full account access, but a leaked one still lets an attacker operate within those scopes. Rotate and audit scope on the next key.

The next 60 seconds matter

The attacker inventories the key's allowed resources (Stripe provides a 'check key permissions' endpoint). Depending on scope, they may read customer lists, issue refunds against allowlisted accounts, create test-mode data to confuse audit trails, or trigger webhooks.

  • Enumerate customers visible to the key
  • Issue actions within granted scopes (refunds, charges if enabled)
  • Trigger webhooks that downstream systems trust

Rotation playbook

  1. Dashboard → Developers → API Keys → Restricted keys → Roll the compromised key
  2. Create the replacement with stricter scope than the original — the leak is a chance to tighten
  3. Review Events log in the 24-hour window around the leak for unexpected actions

Prevent the next one

  • Use restricted keys everywhere possible; reserve the full secret key for admin-only operations
  • Rotate restricted keys quarterly as a default
  • Use signed webhooks with endpoint-secrets (not the main secret key) for webhook validation
Pattern we scan for
rk_live_... / rk_test_...