My secrets file got exposed. What should I do?
Files named secrets.json, credentials.json, auth.json, or .npmrc almost always exist for exactly one reason: they hold sensitive values that the application or toolchain needs at runtime. If any of these files was publicly reachable, assume every token and key inside it has been read. The playbook is the same regardless of the specific filename.
Open the file, catalogue every credential, and start revoking — work fastest to slowest impact.
You can't know exactly what damage has already been done, but you can stop further damage by revoking each credential as quickly as possible. Prioritise by impact: cloud keys and payment tokens first, read-only API keys last.
// the 60-second version
- Read the file carefully and identify every credential type present.
- Revoke and regenerate each token or key in the issuing service's dashboard.
- Remove the file from the web root and add it to
.gitignore. - Replace the file with references to environment variables or a secrets manager.
01Identify what the file likely contains
The name of the file tells you a lot about what's inside. Here are the most common patterns:
secrets.json/credentials.json— application-specific credential stores. May contain database passwords, third-party API keys, service account credentials, or OAuth tokens. The structure varies by application.auth.json— commonly used by Composer (PHP) to store private Packagist credentials:{"http-basic": {"repo.packagist.com": {"username": "token", "password": "..."}}}. Also used by some Node applications for authentication configuration..npmrc— npm configuration file that may contain//registry.npmjs.org/:_authToken=npm_...for publishing packages, or credentials for private registry authentication..pypirc— Python package index credentials: username and password for uploading packages to PyPI or a private repository.
npm publish tokens are particularly dangerous if exposed. An attacker with a valid _authToken for a package you maintain can publish a malicious version of your package to the npm registry — potentially affecting every user who installs or updates it. This is a supply chain attack vector.
02Identify all credentials inside the file
Open the exposed file and make a complete list of every credential. For each entry, note: what type it is, what service issued it, what permissions it has, and where in the relevant service you go to revoke it.
# pretty-print the file to see all keys python3 -m json.tool secrets.json # or search for common credential patterns strings secrets.json | grep -E \ "(password|secret|token|key|auth|api_key|access)" -i
Create a checklist: one row per credential, with columns for: service, credential type, revocation steps, replacement steps, and a checkbox for done. Work through it systematically.
03Revoke each token and credential
For each credential type, go to the issuing service and revoke it explicitly. Generating a new one is not sufficient — the old one must be explicitly invalidated:
- npm tokens — npm website > Account > Access Tokens > Delete the token. Or via CLI:
npm token revoke <token-id> - Composer / Packagist — Packagist.com profile > API Tokens > Revoke the token.
- Database passwords — connect as a database admin and change the user's password with
ALTER USER. - Generic API keys — go to the provider's dashboard, navigate to API keys or developer settings, and delete the exposed key.
- OAuth tokens — revoke via the provider's token management page or the OAuth revocation endpoint (
POST /oauth/revoke).
For npm tokens specifically, check the npm registry for any recently published versions of packages you own. An attacker may have published a malicious patch version. If you find anything suspicious, unpublish the affected version and notify users.
04Regenerate replacements and update the application
For each revoked credential, generate a replacement with the minimum required permissions:
Update your application or toolchain to use the new credential. For .npmrc, update the _authToken value. For secrets.json, update the relevant field. Then verify the application still works correctly with the new credential before moving on.
05Move the file out of the web root and into a secrets manager
A file called secrets.json should never be in a directory served by a web server. Treat this exposure as the final straw for cleaning up your secrets management:
- Move the file above the web root — store it at a path the web server process cannot access, and load its contents at application startup.
- Prefer environment variables — for most use cases, individual environment variables are simpler and safer than a credential file. They can be set per-process, inherited by containers, and never written to disk in a retrievable form.
- Use a dedicated secrets manager — HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, or Azure Key Vault. These systems provide audit logs of every credential access, automatic rotation, and access control policies.
- Add the file to
.gitignore— and run a secrets scan against your git history to check whether the file was ever committed:git log --all --full-history -- secrets.json. - Add a web server deny rule for the specific filename and for common patterns:
Was this guide useful?
These playbooks are free to read and share. If a heads-up ever saved you a bad week, you can say thanks — or jump into the other guides.