Hardcoded Secrets
Some vulnerabilities are loud.
Hardcoded secrets are quiet.
They don’t crash systems or throw errors. They just sit there, waiting to be found.
And once they are, they often unlock everything.
What this page covers
- What hardcoded secrets are: the concept, the mechanics, and the impact
- How to exploit them: discovery techniques and real-world examples
- How to defend against them: secret management and secure development practices
- How to detect them: scanning tools and manual review strategies
- How I’ve practiced it: labs, repos, and CI/CD experiments
This isn’t just about finding keys.
It’s about understanding how trust is stored, and how it can be misplaced.
What Hardcoded Secrets Actually Are
Hardcoded secrets are sensitive values embedded directly into source code, configuration files, or binaries.
These can include API keys, database credentials, encryption keys, tokens, or passwords.
They are often committed to version control, deployed with the application, and accessible to anyone who can read the code or reverse-engineer the app.
The Core Idea:
Secrets are meant to be protected.
Hardcoding them puts them in places they were never meant to live.
Common Examples
- API keys in frontend JavaScript files
- Database credentials in
.envorconfig.php - AWS access keys in Python scripts
- JWT signing secrets in source code
- Hardcoded passwords in mobile apps or firmware
Hardcoded secrets are often found in:
- Public GitHub repositories
- Internal codebases
- Docker images and containers
- Mobile apps and compiled binaries
- CI/CD pipelines and build artifacts
What Happens When They’re Exploited
- Unauthorized access to cloud services or APIs
- Data exfiltration from databases or storage buckets
- Privilege escalation across environments
- Token forgery or session hijacking
- Persistent access through reused or unrotated secrets
Hardcoded secrets don’t just expose data.
They expose trust, and often the keys to the entire system.
How to Mitigate Hardcoded Secrets
1. Use Secret Management Tools
Store secrets in vaults or environment-specific managers.
Examples include HashiCorp Vault, AWS Secrets Manager, Doppler, and Azure Key Vault.
2. Inject Secrets at Runtime
Load secrets dynamically through environment variables or secure APIs.
Avoid embedding them during build or deploy.
3. Scan Codebases for Secrets
Use tools like TruffleHog, Gitleaks, GitGuardian, or custom regex scanners.
Integrate scanning into CI/CD workflows.
4. Rotate Secrets Regularly
Treat secrets like passwords.
Rotate them often and revoke them when exposed.
5. Educate Developers
Make secret hygiene part of the development culture.
Teach why it matters and how to do it right.
Mitigation is about treating secrets like secrets.
Not just values in code, but keys to trust.
How I Practice Hardcoded Secret Discovery
I explore:
- Public GitHub repos with search filters and dorks
- My own projects using Gitleaks and TruffleHog
- Docker images and containers with
stringsand unpacking - Mobile apps using reverse engineering tools
- CI/CD pipelines and build logs for accidental leaks
I test:
- What secrets are exposed
- Where they lead
- How they can be chained with other vulnerabilities
- How to rotate and revoke them safely
Every secret I find teaches me something about how convenience can become compromise.
Final Thought
Hardcoded secrets are simple.
That’s what makes them dangerous.
They’re easy to miss, easy to misuse, and often hard to clean up.
This page is my study of that simplicity.
Not just how to find secrets, but how to protect them, rotate them, and explain why they matter.