/sast-hardcodedsecrets

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 Acce