---

name: sast-hardcodedsecrets description: >- Detect hardcoded sensitive data (API keys, access tokens, private keys, passwords, etc.) in publicly accessible code — frontend JavaScript, mobile apps, client-side bundles, and HTML templates. Uses a three-phase approach: recon (find secret candidates), batched verify (confirm real secrets in public code paths, 3 candidates each), and merge (consolidate batch results). Requires sast/architecture.md (run sast-analysis first). Outputs findings to sast/hardcodedsecrets-results.md. Use when asked to find hardcoded secrets, leaked API keys, or exposed credentials.

Hardcoded Secrets in Public Code Detection

You are performing a focused security assessment to find hardcoded sensitive data that is exposed in publicly accessible code. This skill uses a three-phase approach with subagents: recon (find all potential secret candidates), batched verify (confirm each is a real secret in publicly reachable code, in parallel batches of 3), and merge (consolidate batch reports into one file).

Prerequisites: sast/architecture.md must exist. Run the analysis skill first if it doesn't.

---

What Are Hardcoded Secrets in Public Code

Hardcoded secrets are sensitive credentials — API keys, access tokens, private keys, passwords, signing secrets, database connection strings — embedded directly in source code as string literals.

This skill focuses specifically on secrets that end up in publicly accessible code, meaning an attacker can extract them without any server-side access. A secret hardcoded in backend server code is bad practice but not directly exploitable by an external attacker inspecting the deployed application. A secret hardcoded in frontend JavaScript or a mobile app binary is directly extractable.

The core question: Can an external attacker obtain this secret from the deployed application without server access?

What to Report (Publicly Accessible Code)

These code paths are accessible to attackers after deployment:

• Frontend JavaScript/TypeScript — any .js, .ts, .jsx, .tsx file that runs in the browser. This includes:
  • React, Angular, Vue, Svelte components and pages
  • Next.js client components (files with "use client" or files under app/ without "use server")
  • Nuxt.js pages and client plugins
  • Vanilla JS in public/, static/, or assets/ directories
  • Webpack/Vite/Rollup entry points and their imported modules
  • Any file imported by a client-side entry point (even if it lives in a utils/ or lib/ folder)
• Mobile application code — extractable via reverse engineering (decompiling APK, inspecting IPA):
  • Android: Java/Kotlin source files
  • iOS: Swift/Objective-C source files
  • React Native: JavaScript bundles
  • Flutter: Dart source files
  • Xamarin: C# source files
• HTML files and templates served to clients — inline <script> blocks, data- attributes, meta tags
• Client-side configuration files — files in public/, static/, assets/, www/ directories
• Electron/desktop app source — extractable from ASAR archives
• WebAssembly source/companion JS — secrets in JS glue code or extractable from WASM

What NOT to Report (Backend-Only Code)

Do not flag secrets in these locations — they are not publicly accessible:

• Server-side application code — Express route handlers (server-only), Django views, Flask routes, Spring controllers, Rails controllers, Go HTTP handlers, PHP controllers — code that runs exclusively on the server
• Server-side API route files — Next.js app/api/ routes, Nuxt server routes, SvelteKit +server.ts files
• Environment files — .env, .env.local, .env.production (unless served statically)
• Server-side configuration — config/database.yml, settings.py, application.properties, appsettings.json
• CI/CD pipeline files — .github/workflows/, Jenkinsfile, .gitlab-ci.yml
• Docker/infrastructure files — Dockerfile, docker-compose.yml, Kubernetes manifests
• Backend utility/service files — files that are only imported by server-side code
• Test files — test fixtures and test configuration (unless the test files are shipped to the client)
• Migration files — database migrations

Distinguishing Frontend from Backend

This is critical and requires understanding the project architecture:

Next.js: Files under app/ with "use client" directive or without "use server" are client components. Files under app/api/ are server-only. Files under pages/api/ are server-only. Files under pages/ (non-api) render on both server and client — secrets here ARE exposed. next.config.js runs server-side only but NEXT_PUBLIC_* env vars are embedded in client bundles.

Nuxt.js: Files under pages/, components/, composables/ are client-accessible. Files under server/ are server-only.

React (CRA/Vite): Everything in src/ is bundled for the client. REACT_APP_* and VITE_* env vars are embedded in client builds.

Angular: Everything in src/ is bundled for the client.

Vue (Vite): Everything in src/ is bundled for the client. VITE_* env vars are embedded.

Express/Fastify/Koa: All server-side unless serving static files from a public/ or static/ directory.

Django/Flask: Python code is server-side. Templates are rendered server-side (secrets in template context don't reach the client unless explicitly rendered into JS). Static files in static/ are client-accessible.

Rails: Ruby code is server-side. Assets in app/assets/javascripts/ or app/javascript/ are client-accessible.

Mobile apps: ALL source code is considered publicly accessible via reverse engineering.

---

Types of Secrets to Look For

High-Confidence Patterns (Regex-Identifiable)

These have distinctive formats that make them identifiable with high confidence:

| Secret Type | Pattern | |---|---| | AWS Access Key ID | AKIA[0-9A-Z]{16} | | AWS Secret Access Key | 40-character base64 string near an AKIA key | | Google API Key | AIza[0-9A-Za-z\\-_]{35} | | Google OAuth Client Secret | GOCSPX-[0-9A-Za-z\\-_]{28} | | GitHub Personal Access Token | ghp_[0-9A-Za-z]{36}, github_pat_[0-9A-Za-z_]{82} | | GitHub OAuth App Secret | gho_[0-9A-Za-z]{36} | | GitLab Personal Access Token | glpat-[0-9A-Za-z\\-_]{20} | | Slack Bot/User Token | xoxb-[0-9A-Za-z\\-]+, xoxp-[0-9A-Za-z\\-]+ | | Slack Webhook URL | hooks.slack.com/services/T[A-Z0-9]+/B[A-Z0-9]+/[A-Za-z0-9]+ | | Stripe Secret Key | sk_live_[0-9A-Za-z]{24,} | | Stripe Publishable Key | pk_live_[0-9A-Za-z]{24,} (publishable keys are designed for client-side — skip unless paired with a secret key) | | Twilio Account SID + Auth Token | AC[0-9a-f]{32} (SID), 32-hex auth token nearby | | SendGrid API Key | SG\.[0-9A-Za-z\\-_]{22}\.[0-9A-Za-z\\-_]{43} | | Mailgun API Key | key-[0-9a-zA-Z]{32} | | Firebase Config | apiKey, authDomain, projectId together in a config object — only flag if it includes a server/admin key, not the standard client config | | Private RSA/EC/SSH Key | -----BEGIN (RSA |EC |OPENSSH |DSA |PGP )?PRIVATE KEY----- | | JWT Secret / Signing Key | String assigned to variables like JWT_SECRET, jwt_secret, signingKey, HMAC_KEY | | Database Connection String with Password | postgresql://user:pass@, mysql://user:pass@, mongodb://user:pass@, redis://:pass@ | | Generic API Key Assignment | Variable named *api_key*, *apiKey*, *API_KEY*, *secret*, *SECRET*, *token*, *TOKEN*, *password*, *PASSWORD* assigned a string literal that looks like a real credential | | Heroku API Key | [0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12} in a Heroku context | | Azure Storage Key | Base64 string ~88 chars assigned to storage account key variables | | OpenAI API Key | sk-[A-Za-z0-9]{48} or sk-proj-[A-Za-z0-9\\-_]{100,} | | Anthropic API Key | sk-ant-[A-Za-z0-9\\-_]{90,} |

Variable Name Patterns (Require Value Inspection)

Search for variables/constants with these name patterns and check if the assigned value looks like a real credential:

• api_key, apiKey, API_KEY, ApiKey
• secret, SECRET, secret_key, secretKey, SECRET_KEY
• access_token, accessToken, ACCESS_TOKEN
• auth_token, authToken, AUTH_TOKEN
• private_key, privateKey, PRIVATE_KEY
• password, PASSWORD, passwd, PASSWD
• client_secret, clientSecret, CLIENT_SECRET
• signing_key, signingKey, SIGNING_KEY
• encryption_key, encryptionKey, ENCRYPTION_KEY
• bearer_token, BEARER_TOKEN
• credentials, CREDENTIALS
• connection_string, connectionString, DATABASE_URL

What is NOT a Real Secret (False Positives to Ignore)

• Placeholder values: "your-api-key-here", "TODO", "xxx", "changeme", "REPLACE_ME", "INSERT_KEY", "<api_key>", "dummy", "test", "example", "sample", "placeholder"
• Empty strings: "", ''
• Environment variable references: process.env.API_KEY, os.environ["SECRET"], ENV["KEY"] — these read from the environment at runtime, not hardcoded
• Public keys: Public keys (not private) are designed to be shared — not a secret
• Publishable/public API keys: Stripe pk_test_*, pk_live_*; Firebase client config apiKey (designed for client-side use); Google Maps client key (restricted by HTTP referrer)
• Test/development keys: sk_test_* (Stripe test), keys in files clearly named as test fixtures
• Type definitions / interfaces: TypeScript interface Config { apiKey: string } — no actual value
• Documentation strings: Comments explaining what a key looks like
• Hash values: SHA256/MD5 hashes that are not secrets (e.g., content hashes, checksums)
• Build-time constants: Version strings, build IDs, commit hashes

---

Execution

This skill runs in three phases using subagents. Pass the contents of sast/architecture.md to all subagents as context.

Phase 1: Recon — Find Secret Candidates

Launch a subagent with the following instructions:

Goal: Find every location in the codebase where a hardcoded secret (API key, access token, private key, password, signing secret, connection string) appears as a string literal. Write results to sast/hardcodedsecrets-recon.md.

Context: You will be given the project's architecture summary. Use it to understand the tech stack, project structure, and which files are frontend vs. backend.

What to search for:

Scan the entire codebase. At this stage, flag ALL potential secrets regardless of whether they are in frontend or backend code — the filtering happens in Phase 2.

1. High-confidence regex patterns — search for these distinctive formats:
   • AWS keys: AKIA[0-9A-Z]{16}
   • Google API keys: AIza[0-9A-Za-z\-_]{35}
   • GitHub tokens: ghp_, github_pat_, gho_, ghs_
   • Slack tokens: xoxb-, xoxp-, xoxa-, xoxr-
   • Stripe secret keys: sk_live_, sk_test_
   • SendGrid keys: SG\.
   • OpenAI keys: sk- followed by 48+ alphanumeric characters
   • Anthropic keys: sk-ant-
   • Private key headers: -----BEGIN.*PRIVATE KEY-----
   • Connection strings with embedded passwords: ://[^:]+:[^@]+@
2. Variable assignment patterns — search for variables with secret-related names assigned string literal values:
   • Search for patterns like: apiKey = "...", api_key = '...', API_KEY: "...", secret: "...", token = "...", password = "...", client_secret = "..."
   • Include all casing conventions: camelCase, snake_case, SCREAMING_SNAKE_CASE, PascalCase
   • Look in JS/TS objects, JSON files, YAML/TOML config, Python dicts, environment-like configs
3. Inline string literals that match known key formats:
   • Long random alphanumeric strings (32+ characters) assigned to auth-related variables
   • Base