API Security Secrets Management
Every API depends on secrets: database passwords, signing keys, API keys, tokens, and certificates. A leaked secret gives an attacker the same power as the service that owns it. Secrets management covers how teams store, share, rotate, and retire these values safely.
Layman's Explanation
A building manager keeps spare keys in a locked cabinet. A sign-out sheet records who took which key and when. Nobody tapes a key to the front door. Secrets management gives software teams the same cabinet, the same sign-out sheet, and a habit of changing locks on a schedule.
Where Secrets Leak
- Source code and public repositories
- Configuration files committed with the project
- Chat messages, tickets, and emails
- Build logs and error messages
- Mobile app packages and browser scripts
- Container images that bake in credentials
Automated bots scan public repositories around the clock. A key pushed by mistake can face abuse within minutes.
The Secret Lifecycle
CREATE ----> STORE ----> DELIVER ----> USE ----> ROTATE ----> REVOKE
| | | | | |
strong, encrypted short-lived least scheduled immediate
random vault access privilege renewal on leak
Storage Options
| Method | Safety Level | Notes |
|---|---|---|
| Hard-coded in source | Very poor | Never acceptable |
| Plain config file | Poor | Easy to copy and commit |
| Environment variables | Fair | Suits small setups, appears in process dumps |
| Secrets manager or vault | Strong | Encryption, access rules, audit trail |
| Hardware security module | Very strong | Keys never leave the device |
Core Practices
Use a Dedicated Vault
Cloud providers and open source tools offer managed secret stores. They encrypt values, restrict who reads them, and record every access.
Fetch Secrets at Runtime
The application requests a secret when it starts, using its own identity. The value never lives in the code or the image.
Prefer Short-Lived Credentials
A token that expires in an hour limits the damage of a leak. Dynamic secrets, issued per session and deleted afterward, reduce risk further.
Separate Environments
Development, testing, and production each use different secrets. A developer laptop never holds a production key.
Rotate on a Schedule
Replace secrets every few months, and replace them at once when a team member leaves. Design the application to accept a new value without downtime.
Scan Continuously
Secret scanners inspect commits, pull requests, and history. Run them on developer machines and in the build pipeline so a leak stops before it ships.
When a Secret Leaks
- Revoke the exposed credential immediately
- Issue a replacement and deploy it
- Review logs for misuse during the exposure window
- Remove the secret from history and notify affected owners
- Record the cause and fix the process that allowed it
Deleting a file does not erase a secret. Version history keeps the old value, so treat every exposed secret as compromised.
Access Rules for Secrets
Grant each service access to its own secrets only. Log every read. Alert on unusual access, such as a build job reading production keys. Review who holds access every quarter and remove anyone who no longer needs it.
Secrets in Mobile and Browser Apps
Code that runs on a user's device is visible to that user. Anyone can unpack a mobile app or read browser scripts and extract embedded keys. Keep powerful secrets on the server. Let the app call your own backend, and let the backend call third-party services. Issue the app only low-privilege, short-lived tokens tied to the logged-in user.
Documentation and Ownership
Record an owner for every secret, the systems that use it, and the rotation date. A forgotten secret with no owner never rotates and never gets revoked. An inventory also speeds up response when a vendor announces a breach.