Prompt of the Day: Audit Your Project for Hardcoded Secrets

The Task

You want to scan your entire codebase for hardcoded API keys, passwords, tokens, and exposed credentials before you ship — or before you find out the hard way that you already leaked them.

The Prompt

You are a security auditor specializing in secrets detection. Scan this entire project for hardcoded secrets, exposed credentials, and insecure secret handling. Be thorough and systematic.

Check every file in the codebase — source code, config files, comments, test files, scripts, and documentation — for:

1. **API keys and tokens**: Look for patterns like `sk-`, `pk_`, `ghp_`, `Bearer `, `xox`, `AKIA` (AWS), and any long alphanumeric strings assigned to variables named `key`, `token`, `secret`, `api_key`, `auth`, `credential`, or similar.
2. **Passwords and connection strings**: Database URLs, connection strings with embedded credentials, and any variable named `password`, `passwd`, `pwd`, `db_pass`, or similar with a hardcoded value.
3. **Private keys and certificates**: PEM blocks, RSA/EC private keys, or base64-encoded blobs that look like encoded credentials.
4. **Committed .env files**: Check if any `.env`, `.env.local`, `.env.production`, or similar files exist and are not in `.gitignore`.
5. **Secrets in comments or TODOs**: Developers often leave credentials in comments like `# TODO: remove this key: abc123`.
6. **Base64-encoded secrets**: Decode any suspicious base64 strings — AI tools and developers sometimes encode credentials thinking it hides them.
7. **.gitignore coverage**: Verify that `.env*`, `*.pem`, `*secret*`, and `*credential*` patterns are listed.

For each finding, report:
- File path and line number
- The type of secret (API key, password, token, etc.)
- Severity: CRITICAL (production credential), HIGH (any real-looking secret), MEDIUM (test/dummy values that follow real patterns), LOW (poor practice but no real secret)
- Remediation: exact steps to fix it (environment variable name to use, whether to rotate the credential, whether to purge from Git history)

End with a summary checklist of all issues found and a prioritized fix order.

Why It Works

This prompt works because it's specific about what to look for — it gives the AI named patterns (sk-, AKIA, ghp_), variable name heuristics, and file types to check, rather than leaving the AI to guess. It also asks for structured output (file path, severity, remediation), which forces the AI to be systematic instead of vague. Finally, the base64 check catches the sneaky pattern where developers or AI tools encode credentials thinking obfuscation equals security.

The Anti-Prompt

Don't use this:

check my code for security issues

Why it fails: This is too vague to be useful. The AI has no idea you care about secrets specifically — it might spend all its tokens on SQL injection, XSS, or dependency vulnerabilities and mention hardcoded keys in a single bullet at the bottom. You'll get a generic security summary instead of an actionable secrets audit. Vague prompts produce vague results.

Variations

For Python projects:

Audit this Python project for hardcoded secrets. Focus on: hardcoded strings in settings.py, django/flask config files, and any os.environ.get() calls with fallback values like os.environ.get("API_KEY", "hardcoded-fallback"). Check requirements.txt for packages that handle auth and verify their keys aren't committed. Flag any use of python-dotenv where the .env file itself is tracked in Git.

For general web apps (Next.js / Node / React):

Scan this web application for exposed secrets. Check: next.config.js and any NEXT_PUBLIC_ variables that expose server secrets to the client, .env files committed to the repo, hardcoded fetch() calls with API keys in headers, and any secrets accidentally bundled into client-side JavaScript. Confirm the .gitignore properly excludes all .env variants and verify no secrets appear in public/ or build output.

Level Tag

[Beginner]