DEV.co
Open-Source Security · blacklanternsecurity

badsecrets

BadSecrets is a Python library that detects the use of known or weak cryptographic secrets (like default API keys, machine keys, and signing passwords) across 20+ web frameworks and platforms. It works by analyzing existing cryptographic artifacts (cookies, tokens, URLs) offline or by actively testing live targets to confirm whether they accept known secrets.

Source: GitHub — github.com/blacklanternsecurity/badsecrets
810
GitHub stars
82
Forks
Python
Primary language
AGPL-3.0
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
Repositoryblacklanternsecurity/badsecrets
Ownerblacklanternsecurity
Primary languagePython
LicenseAGPL-3.0 — OSI-approved
Stars810
Forks82
Open issues2
Latest release1.2.0 (2026-06-19)
Last updated2026-07-07
Sourcehttps://github.com/blacklanternsecurity/badsecrets

What badsecrets is

The library provides passive modules that decrypt/verify cryptographic products against a database of known secrets, and active modules that use YARA-based fingerprinting to forge tokens and test them against live targets. It abstracts away platform-specific implementation details, supporting frameworks like ASP.NET, Django, Flask, Rails, Express, Laravel, Symfony, JSF, Shiro, and others.

Quickstart

Get the badsecrets source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/blacklanternsecurity/badsecrets.gitcd badsecrets# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Security assessments of multi-framework environments

Quickly identify if common default or well-known secrets are in use across heterogeneous application stacks without writing framework-specific detection code.

CI/CD secret scanning and DevOps automation

Integrate into pipelines to passively check for weak signing keys in session tokens, JWTs, and signed cookies before deployment.

Penetration testing and red team operations

Use active modules to probe live targets for default credentials in Shiro, GlobalProtect, WebSphere, and other enterprise platforms without requiring sample tokens.

Implementation considerations

  • Requires Python; intended for security teams and DevOps practitioners rather than application developers integrating into product code.
  • Active modules perform network requests to targets; ensure proper authorization and network policies before enabling (use --passive-only flag to disable).
  • Secret database is maintained by the project; keep the library updated regularly to benefit from new known secrets added upstream.
  • Passive modules work offline but depend on having access to the cryptographic artifacts (cookies, tokens, URLs) you wish to test.
  • Custom secrets can be supplied via CLI (--custom-secrets) for organization-specific or legacy systems not in the default database.

When to avoid it — and what to weigh

  • Need permissive open-source licensing for proprietary products — AGPL-3.0 requires source code disclosure and derivative work licensing under AGPL. Commercial/proprietary use without open-sourcing is not permitted without a separate commercial license agreement.
  • Require detection of zero-day or custom secrets — The library only detects secrets already in its hardcoded database. It cannot identify novel, organization-specific, or randomly generated secrets.
  • Need offline-only operation without active probing — Active modules (Shiro, GlobalProtect, LTPA) make unsolicited authentication attempts to live targets, which may trigger WAF/IDS alerts or violate compliance policies.
  • Working in highly regulated environments with strict third-party dependencies — Using an AGPL tool may introduce compliance friction; review with legal/security teams before adoption.

License & commercial use

Licensed under AGPL-3.0 (GNU Affero General Public License v3.0). This is a copyleft license that requires any derivative works or modifications to be released under the same AGPL-3.0 license and source code to be made available to users. Network use (e.g., SaaS) triggers source disclosure obligations.

AGPL-3.0 is not compatible with closed-source commercial products without explicit licensing agreement. If you integrate BadSecrets into proprietary software or provide it as a service, you must open-source your modifications under AGPL-3.0 or negotiate a separate commercial license with the copyright holder (Black Lantern Security). Using it as a standalone assessment tool in your own organization carries lower risk but should be reviewed with legal counsel.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

SignalAssessment
MaintenanceActive
DocumentationAdequate
License clarityClear
Deployment complexityLow
DEV.co fitGood
Assessment confidenceHigh
Security considerations

BadSecrets itself is a detection tool, not a cryptographic engine. Its security posture depends on: (1) accuracy of the known-secrets database (external validation advised); (2) correct implementation of cryptographic verification (HMAC, RSA) against target platforms—mismatches could cause false negatives; (3) active modules send forged authentication tokens to targets, which could be flagged as attack activity by WAF/IDS; (4) the tool does not validate targets before testing; operator must ensure authorization. No independent security audit or penetration test results are provided in the data.

Alternatives to consider

Blacklist3r

Original inspiration for BadSecrets; language-specific and OS-dependent; less actively maintained and narrower framework coverage.

flask-unsign (standalone)

Focused detection for Flask signed cookies only; lighter weight but no multi-framework abstraction or active probing.

Custom YARA rules or Burp extensions

Full control over detection logic but requires significant development effort; no pre-built secret database.

Software development agency

Build on badsecrets with DEV.co software developers

Use BadSecrets to identify common default secrets and weak signing keys in your CI/CD pipelines and security assessments. Works with 20+ frameworks out of the box.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

badsecrets FAQ

Can I use BadSecrets in a commercial product or service?
Not without a separate commercial license or open-sourcing your modifications under AGPL-3.0. Using it as a standalone security assessment tool in your own organization is lower-risk but should be reviewed with legal counsel.
Does BadSecrets detect all known secrets?
No. It detects only secrets in its hardcoded database (common defaults, tutorial examples, documented vulnerabilities). Custom or randomly generated secrets will not be detected.
Can BadSecrets detect secrets in live applications without a sample token?
Yes, through active modules (Shiro, GlobalProtect, LTPA, etc.) that fingerprint and forge tokens. These make network requests to targets; ensure you have authorization before running them.
What Python versions are supported?
Not clearly stated in the data provided. Check the PyPI package or repository README for version requirements.

Work with a software development agency

Adopting badsecrets is usually one piece of a larger software development effort. As a software development agency, DEV.co provides software development services and web development expertise — pairing senior software developers and web developers with your team to design, build, and operate open-source security software in production.

Secure Your Multi-Framework Applications

Use BadSecrets to identify common default secrets and weak signing keys in your CI/CD pipelines and security assessments. Works with 20+ frameworks out of the box.