OWASP WrongSecrets is a security training project and practice environment focused on finding and fixing hardcoded or mismanaged secrets in software and infrastructure. It helps defenders recognise where credentials leak into source code, images, logs, or configuration. Use it to test secret discovery, rotation, and remediation workflows before those weaknesses appear in production.
What OWASP WrongSecrets Helps Teams Practice
OWASP WrongSecrets is best understood as a hands-on learning environment for secret discovery and remediation, not just a reference page about bad password handling. It gives defenders a safe place to examine how hardcoded credentials and other secret material appear in real development and operations workflows.
That matters because secret exposure is often boring in appearance and severe in outcome. A leaked API key, token, certificate, or password can turn source repositories, build artifacts, logs, and config files into access paths that outlive the original mistake.
Where Secrets Commonly Leak
The project focuses attention on the places defenders most often miss: source code, container images, CI/CD variables, logs, manifests, and configuration stores. Those are the channels where a secret can move from intended private use into widely distributed, searchable, or reusable material.
In practice, the problem is not only that a secret exists, but that it is copied into multiple layers of the delivery chain. Once a credential lands in an image layer, a pipeline variable, or a committed config file, revocation becomes harder and detection often lags exposure.
For teams building a broader secrets programme, NHIMG’s Secrets Management Guide is the natural companion because it covers centralisation, secret zero, rotation, dynamic secrets, and secretless patterns.
Why Hardcoded Secrets Are Dangerous
Hardcoded or mismanaged secrets create a durable trust failure. Unlike a transient bug, a secret can be reused silently, exfiltrated without changing the application’s visible behaviour, and inherited by downstream systems that were never meant to hold it.
The danger scales quickly when one secret unlocks many systems or when old copies continue to work after the original owner has moved on. That is why secret sprawl, long-lived secrets, and unmanaged rotation are operational problems as much as code-quality problems.
OWASP guidance such as the OWASP ASVS and the OWASP Top 10 help frame the issue as a combination of authentication weakness, configuration failure, and insufficient verification rather than a single coding mistake.
How Teams Test, Detect, and Remediate
WrongSecrets is useful because it lets teams rehearse the full response path: detect a secret, confirm where it is used, rotate or revoke it, and verify that the system still functions after the change. That workflow is the real test, because discovery alone does not reduce exposure if the remediation path is slow or incomplete.
Detection should include source scanning, image and artifact inspection, log review, and checks for secrets embedded in environment files or build-time configuration. Remediation then needs ownership, replacement, and verification, so the old value is no longer accepted anywhere it was trusted.
The same control logic is reflected in the OWASP Web Security Testing Guide and the OWASP SAMM, which together support repeatable testing and maturity-building across the delivery lifecycle.
How It Fits into Secure Engineering Practice
As a training project, OWASP WrongSecrets is most valuable when it is used to change behaviour, not just to score a lab exercise. The point is to teach engineers, platform teams, and security reviewers how to prevent secret exposure before code reaches production, and how to prove that fixes actually remove the exposure path.
That makes it especially useful for secure development programmes, pipeline hardening, and incident readiness exercises where secret handling is a recurring control objective. It is also a good way to align application teams around the idea that secret rotation, vaulting, and detection are part of software quality, not separate afterthoughts.
For a structured application-security baseline, the OWASP ASVS Guide provides the verification context that helps turn secret-handling lessons into lasting engineering requirements.
Risk and Threat Considerations
Secret exposure is dangerous because a single leaked value can become persistent unauthorised access, often without obvious runtime symptoms. The threat is not limited to direct theft, it also includes reuse, lateral movement, and silent access through systems that still trust the exposed credential.
Failure mechanism: A secret is embedded in code, logs, images, or config, then copied into places the owner does not fully control, allowing an attacker or insider to retrieve and reuse it before rotation or revocation closes the path.
Impact: Compromise can extend beyond one application to API access, cloud resources, signing workflows, or downstream services that trust the same credential, especially when secrets are long-lived or broadly reused.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V6 — Authentication | Secret handling directly affects authentication material and how credentials are verified and protected. |
| V9 — Self-contained Tokens | Tokens are identity-bearing secrets that can be exposed, replayed, or reused if mismanaged. | |
| V13 — Configuration | Hardcoded secrets commonly appear in configuration and deployment settings. | |
| Recommendation — Verify that authentication material is never hardcoded and that secret handling supports secure authentication flows. Check that token storage and handling prevent disclosure, replay, and unintended reuse. Review configuration pathways to eliminate embedded secrets and enforce external secret injection. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers lifecycle management of authenticators, including rotation and protection of secret material. |
| SC-12 — Cryptographic Key Establishment and Management | Secret material often includes keys that require controlled generation, storage, and rotation. | |
| Recommendation — Manage authenticator lifecycle so exposed credentials can be rotated or revoked quickly. Apply controlled key management to prevent long-lived or exposed cryptographic material from persisting. | ||
| CIS Controls v8 | CIS-5 — Account Management | Secrets often grant account access, so account lifecycle controls are central to remediation after exposure. |
| Recommendation — Revoke or replace exposed access paths and confirm unused accounts or keys are removed. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Secret exposure directly undermines authentication and access control protections. |
| Recommendation — Enforce authentication and access controls so leaked secrets do not become durable access paths. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org