Hardcoded secret in a JSON/YAML/TOML config key
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 8 points from that category, once per scan, no matter how many places it turns up.
What it detects
A secret/api_key/access_token/client_secret key in a structured config file holds a concrete high-entropy literal rather than an environment reference. The credential is then committed and shared with the whole repo.
Why it matters
A concrete secret in a structured config file (YAML, JSON, TOML) is committed and shared with everyone who has the repo, and it lingers in git history after removal. Unlike env files, these config files are often assumed safe to commit, which is exactly why leaked keys hide in them. Any api_key or client_secret set to a real value should be treated as exposed.
How to fix it
Replace the literal with an environment-variable reference and load it at runtime, keeping the real value in your host secret store with a placeholder in .env.example. Rotate the exposed secret with its provider. Where the config format supports interpolation, use it to pull the value from the environment.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo