AL-JANEF Secrets Guard
A leaked secret is one of the fastest paths to a breach — a single committed API key can hand an attacker the whole system. This skill keeps secrets out of the places they leak from, and cleans them up when they've already landed there.
The rule underneath everything: a secret belongs in the runtime environment, never in the source. If it's in a file that gets committed, shipped to the browser, or printed to a log, treat it as compromised.
When to reach for this skill
Use it whenever code touches credentials: adding an API key, wiring up a database
connection, configuring an external service (payment, messaging, storage),
setting up .env files, or committing configuration. Also whenever the user asks
where to store a key or whether something is safe to commit. The presence of a
credential is the trigger.
What to do
1. Detect secrets already present
Scan for hardcoded credentials in the code and config: high-entropy strings,
apiKey = "...", connection strings with embedded passwords, private key blocks,
tokens in source. Common shapes: cloud keys, database URLs like
postgres://user:pass@host, JWT signing secrets, third-party service keys
(payment, messaging). Also check what's already committed to git history, not
just the working tree — a secret removed from the current code but still in
history is still leaked.
If a real secret is found in code or history: flag it as compromised and
requiring rotation, not just removal. Once a secret has been committed to a shared
repo, deleting it doesn't un-leak it — it must be rotated (regenerated) at the
provider. See references/leak-response.md.
2. Move secrets to the environment
Secrets load from environment variables (or a secret manager), never from source:
// wrong — in source
const key = "replace-me";
// right — from environment
const key = process.env.STRIPE_SECRET_KEY;
Provide a committed .env.example with the names and dummy values, and keep the
real .env untracked. For production, prefer a managed secret store (the
platform's secret manager) over shipping .env files around.
3. Watch the client boundary
The most dangerous secret leak in modern frameworks: putting a secret in code
that ships to the browser. In Next.js and similar, anything prefixed for client
exposure (e.g. NEXT_PUBLIC_*) is embedded in the bundle and readable by anyone.
A secret must never carry a public/client prefix. Only truly public values
(publishable keys designed for the client) belong there. Verify which side of the
client/server boundary each key lives on.
4. Prevent recurrence
Set up guards so secrets can't slip in again:
.gitignoreincludes.env,.env.*(but allow.env.example).- A pre-commit secret scanner (gitleaks, or a hook) blocks commits containing secret-shaped strings.
- Never log secrets — check that error handlers and request loggers don't print auth headers, tokens, or connection strings.
See references/setup.md for concrete gitignore, .env.example, and pre-commit
scanner configuration.
Output format
When auditing, report clearly and rank by exposure:
## Secrets Audit: <target>
### Exposed / compromised (rotate immediately)
- <secret type> at <location> — committed / in history / in client bundle → rotate + remove
### Misplaced (move to environment)
- <secret> hardcoded at <location> → move to env var <NAME>
### Prevention gaps
- <e.g. .env not gitignored, no pre-commit scan>
### Verified good
- <secrets correctly externalized>
Do not print the full secret value in the report — reference it by type and
location (Stripe secret key in config.js:12), show at most a masked fragment.
Printing it in full just copies the leak into a new place.
Proof before done
Demonstrate the fix: the secret no longer appears in the built client bundle (grep the build output), the app still runs reading from env, and the pre-commit scanner actually blocks a test secret. For a rotated key, confirm the old one is revoked at the provider.
References
references/setup.md— Copyable.gitignore,.env.example, and pre-commit secret-scanner config. Read it when setting up prevention.references/leak-response.md— Step-by-step response when a real secret has already been committed (rotate, purge, prevent). Read it when a live leak is found.