The hook
Secret formats are public knowledge. Stripe documents them, AWS documents them, GitHub documents them, OpenAI documents them β the prefixes and shapes are part of the API spec, intentionally distinguishable so SDKs can validate input early. The same documentation that helps developers also helps attackers and the dozens of automated scrapers continuously scanning the public web for leaked credentials. A leaked key is instantly recognizable: `sk_live_` prefix means Stripe live secret, `AKIA` prefix means AWS access key, `ghp_` prefix means GitHub personal access token, `sk-` prefix with the right length means an OpenAI key. The pattern is the punishment.
Na sala e cakacaka kina
Each cloud and SaaS uses a distinct secret format with stable enough properties to support high-precision regex matching. Stripe: `sk_live_[a-zA-Z0-9]{24,99}` for live secrets, `pk_live_[β¦]` for publishable, `whsec_[β¦]` for webhook secrets. AWS: `AKIA[0-9A-Z]{16}` for IAM access key IDs, `ASIA` prefix for STS temporary credentials. GitHub: `ghp_` for classic PATs, `gho_` for OAuth tokens, `ghu_` for user-to-server, `ghs_` for server-to-server, `ghr_` for refresh. OpenAI: `sk-[a-zA-Z0-9]{48}` (varies by tier). Slack: `xox[baprs]-[β¦]` family. Supabase service-role JWTs have a recognizable header structure. We curate ~18 patterns covering the most common, highest-impact services.
The variants
Stripe / payment processor keys
Live secret keys reveal the live billing account. Test secrets are less impactful but still indicate poor practice. Webhook secrets, when leaked, let attackers forge events.
Cloud provider IAM credentials
AWS AKIA, GCP service-account keys, Azure SAS tokens. Often paired with the secret-key half nearby in the same file. Full cloud access if the role is permissive.
Source-code provider tokens
GitHub PATs (especially with `repo` scope), GitLab tokens, Bitbucket app passwords. Source code access = secrets-in-history access = the cycle continues.
Service-role / admin tokens
Supabase service-role JWTs, Firebase admin SDK creds, internal service tokens. These bypass app-level authorization entirely.
The blast radius
Tracks the leaked secret. Stripe live keys are billing takeover β refund operations, fraudulent charges, customer data exposure. AWS keys are full cloud access depending on role policy; permissive roles are RCE-class. OpenAI keys are bill-driving abuse (attackers run inference on your account until your spending limits trigger). GitHub PATs with repo scope are source code, CI secrets, and often the keys-to-everything-else. Service-role tokens (Supabase, Firebase) bypass RLS entirely and grant full database access. Each is potentially business-ending depending on what's behind it.
// what fixvibe checks
What FixVibe checks
FixVibe checks shipped client assets for high-confidence secret exposure signals and known credential formats. Reports identify the affected asset and rotation path. For check-specific questions about exact detection heuristics, active payload details, or source-code rule patterns, contact support@fixvibe.app.
Ironclad defenses
Don't hardcode secrets in client code. Use environment variables, scoped to server-side only β `process.env.STRIPE_SECRET_KEY` should not be referenced in any file that ships to the client bundle. Mark server-only files with `import 'server-only'` (Next.js) or equivalent so a stray client import becomes a build error. Add CI scanners β gitleaks pre-commit, trufflehog in PRs, FixVibe's own bundle scanner pre-deploy β and treat any positive as a deployment-blocking event. Rotate any secret that has ever appeared in a public response, regardless of how briefly. Use secret-management tooling (Vercel env vars, AWS Secrets Manager, HashiCorp Vault, Doppler, 1Password Secrets Automation) so secrets aren't committed to source in the first place. As a final layer, scope every credential to the minimum permissions and shortest lifetime your use case allows β so even when leaks happen, the damage is contained.
The takeaway
The fix isn't a tool, it's the mental model: there are public secrets and there are private secrets, and the rules are different. Treat the client bundle as a publication channel.
