Goal: Verify the following hardcoded secret candidates. For each one, determine (1) whether it is a real secret and (2) whether it is in publicly accessible code. Write results to sast/hardcodedsecrets-batch-[N].md.
Your assigned candidates (from the recon phase):
[Paste the full text of the assigned candidate sections here, preserving the original numbering]
Context: You will be given the project's architecture summary. Use it to understand the tech stack, frontend/backend separation, build pipeline, and which directories contain client-side vs. server-side code.
For each candidate, answer TWO questions:
Question 1: Is this a real secret?
Check whether the value is an actual credential vs. a false positive:
- Does the string have the entropy and format of a real key/token? (Real API keys are typically 20+ random characters)
- Is it a known placeholder or example value? ("your-key-here", "changeme", "test", "example", "TODO", "xxx", "REPLACE_ME", etc.)
- Is it a test/development key? (Stripe
sk_test_*, sandbox credentials, keys in test fixtures)
- Is it a public/publishable key by design? (Stripe
pk_live_*, Firebase client apiKey, Google Maps browser key)
- Is it actually an environment variable reference that got picked up by mistake?
- Is it a hash, checksum, or non-secret identifier?
If the value is NOT a real secret, classify as Not Vulnerable and explain why.
Question 2: Is this in publicly accessible code?
Determine whether an external attacker can extract this secret from the deployed application:
PUBLICLY ACCESSIBLE (report these):
- Frontend JavaScript/TypeScript that runs in the browser (React, Angular, Vue, Svelte components/pages)
- Next.js client components (files with
"use client" or client-rendered pages)
- Nuxt.js
pages/, components/, client-side plugins/
- Any
.js/.ts file that is imported by a client-side entry point (trace the import chain)
- Files in
public/, static/, assets/, www/ directories that are served directly
- HTML files with inline
<script> blocks
- Mobile app source code — Android (Java/Kotlin), iOS (Swift/Objective-C), React Native JS, Flutter Dart, Xamarin C# — ALL mobile code is extractable via reverse engineering
- Electron app source (extractable from ASAR)
- Client-side configuration objects embedded in JavaScript (e.g., Firebase config, analytics init)
NOT PUBLICLY ACCESSIBLE (do not report):
- Server-side route handlers (Express, Django, Flask, Rails, Spring, Go, PHP controllers)
- Server-side API routes (Next.js
app/api/, Nuxt server/, SvelteKit +server.ts)
- Backend services, middleware, utilities only imported by server code
.env files, server config files, Docker/CI files- Test files and fixtures not shipped to clients
- Database migrations
- Build scripts and tooling
How to determine if a file is client-side:
- Check the file path — is it under a client-side directory? (
src/ in CRA/Vite React, pages/ in Next.js, app/ in Angular, src/ in Vue)
- Trace the import chain — is this file imported (directly or transitively) by a client-side entry point?
- Check for server-only markers —
"use server" directive, file under api/ or server/ directories
- Check
sast/architecture.md for the project's frontend/backend separation pattern
- For ambiguous cases (e.g., shared utility files), err on the side of caution — if it COULD be bundled for the client, treat it as publicly accessible
If the secret is NOT in publicly accessible code, classify as Not Vulnerable and explain why (e.g., "Server-side only — Express route handler").
Classification:
- Vulnerable: Confirmed real secret in confirmed publicly accessible code. An attacker can extract this from the deployed application.
- Likely Vulnerable: Appears to be a real secret and the file is likely client-accessible, but cannot fully confirm one or both conditions (e.g., ambiguous import chain, uncertain if the value is a real production key).
- Not Vulnerable: Either not a real secret (placeholder, test key, public key) OR not in publicly accessible code (backend-only).
- Needs Manual Review: Cannot determine if the value is a real secret or if the file reaches the client — requires human judgment.
Output format — write to sast/hardcodedsecrets-batch-[N].md:
# Hardcoded Secrets Batch [N] Results
## Findings
### [VULNERABLE] Descriptive name
- **File**: `path/to/file.ext` (lines X-Y)
- **Secret type**: [AWS key / Google API key / etc.]
- **Exposure path**: [How an attacker extracts it — e.g., "Bundled into client JS via Webpack, visible in browser DevTools Sources tab" or "Embedded in Android APK, extractable via `apktool d app.apk`"]
- **Issue**: [Clear description — e.g., "AWS access key hardcoded in React component that is bundled for the browser"]
- **Impact**: [What an attacker can do with this secret — e.g., "Full access to AWS S3 buckets, potential data exfiltration", "Send emails via SendGrid on behalf of the organization", "Access user data via the API"]
- **Evidence**:
[Code snippet with the secret value partially redacted]
- **Remediation**: [Move the secret to a server-side environment variable. If the client needs to call this API, proxy through your backend. For mobile apps, use a backend proxy or OAuth flow instead of embedding keys.]
- **Verification Steps**:
[How to confirm this finding:
- For web apps: "Open browser DevTools > Sources > search for 'AKIA' in bundled JS files"
- For mobile apps: "Run
apktool d app.apk and grep for the key pattern"
- For Electron: "Extract ASAR archive and search for the key"]
### [LIKELY VULNERABLE] Descriptive name
- **File**: `path/to/file.ext` (lines X-Y)
- **Secret type**: [type]
- **Exposure path**: [Best guess at how it reaches the client]
- **Issue**: [What's uncertain]
- **Concern**: [Why it's still a risk]
- **Evidence**:
[Code snippet]
- **Remediation**: [Fix recommendation]
### [NOT VULNERABLE] Descriptive name
- **File**: `path/to/file.ext` (lines X-Y)
- **Reason**: [e.g., "Placeholder value — 'your-api-key-here'" or "Server-side only — Django view, never reaches the client" or "Stripe publishable key — designed for client use"]
### [NEEDS MANUAL REVIEW] Descriptive name
- **File**: `path/to/file.ext` (lines X-Y)
- **Uncertainty**: [Why automated analysis couldn't determine the status]
- **Suggestion**: [What to check manually]
