# Why API Secret Leakage Audit Exists

Scans HTML + JS for 20+ secret patterns: AWS, Stripe live, Twilio, OpenAI, Anthropic, GitHub PAT, Slack tokens, JWTs, private keys.

Author: J.A. Watte
Published: April 23, 2026
Source: https://jwatte.com/blog/blog-tool-api-secret-leakage-audit/

---

**TL;DR.** Browsers fail closed on missing security headers — one wrong directive converts a production site into an XSS or data-exfiltration surface, and the failure is silent until a breach or PCI review.

The **[API Secret Leakage Audit](/tools/api-secret-leakage-audit/)** is the audit you reach for when you already suspect a problem in this dimension and need a fast, copy-paste-able fix list. It reuses the same chrome as every other jwatte.com tool — deep-links from the mega analyzers, AI-prompt export, CSV/PDF/HTML download — but the checks it runs are narrow and specific to the dimension described above.

> Scans the initial HTML and inline/external JS for exposed API keys: AWS access keys, Stripe live keys, Twilio auth tokens, Google Maps keys, Firebase config, JWT tokens, private keys. Common supply-chain leak vector.

## What it actually checks

Extract of the audit's real findings — the same strings the tool prints when a check trips. Use this as a sanity check before you run the audit live:

**Warnings (fix these same-month):**

- dotenv / .env object referenced in client code

**Info-only (context for the fix plan — not a failure):**

- Firebase initializeApp() config detected

## Why this dimension matters

Modern browsers fail closed on missing or misconfigured security headers — a single wrong header (CSP with `unsafe-inline`, ACAO wildcard with `Allow-Credentials: true`, SRI hash mismatch) turns a production site into an XSS or data-exfiltration risk. Audit-side these are silent; users notice only after a breach or a PCI / SOC-2 review asks.

## Common failure patterns

- **Permissive CORS combined with credentials** — `Access-Control-Allow-Origin: *` plus `Access-Control-Allow-Credentials: true` is ignored by browsers but signals sloppy review. The real failure is ACAO echo-back (reflecting any `Origin` header) paired with credentials; that exposes authenticated endpoints to cross-site scripts.
- **CSP `unsafe-inline` / `unsafe-eval`** — a CSP that allows inline or eval defeats most of its own purpose. Modern apps should emit nonces or hashes and remove inline handlers; the audit flags the pattern and points to the `Trusted Types` + `Inline Event Handler` tools as the next step.
- **Security headers on HTML but not on APIs** — the HTML response gets HSTS, CSP, and X-Frame-Options; the JSON API response doesn't. An attacker only needs one unhardened origin.

## How to fix it at the source

Start from a deny-by-default CSP and relax per directive. For CORS, prefer an explicit allowlist over `*`. Apply headers at the CDN / edge layer (Netlify `_headers`, Vercel `vercel.json`, Cloudflare Transform Rules, nginx `add_header`) rather than in application code — the edge layer catches every response consistently.

## Thresholds that matter

| Signal | Target |
|---|---|
| HSTS max-age | ≥ 15552000 (180 days). Preload list eligibility requires 31536000 + includeSubDomains + preload. |
| CSP unsafe-inline | Zero in a hardened policy. Use nonces or hashes instead. |
| SRI coverage on cross-origin scripts | 100%. Any missing hash is a supply-chain vector. |
| X-Frame-Options / frame-ancestors | DENY or SAMEORIGIN (or `frame-ancestors 'none'` in CSP). |
| Referrer-Policy | `strict-origin-when-cross-origin` or stricter. |

## Example fix

_Netlify `_headers` starter (replace the wildcards with real origins):_

```nginx
/*
  Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-REPLACE'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'
  Referrer-Policy: strict-origin-when-cross-origin
  X-Content-Type-Options: nosniff
  Permissions-Policy: camera=(), microphone=(), geolocation=()
  Cross-Origin-Opener-Policy: same-origin
  Cross-Origin-Embedder-Policy: require-corp

/api/*
  Access-Control-Allow-Origin: https://app.yoursite.com
  Access-Control-Allow-Credentials: true
  Vary: Origin
```

## When to run the audit

- After a major site change — redesign, CMS migration, DNS change, hosting platform swap.
- Quarterly as part of routine technical hygiene; the checks are cheap to run repeatedly.
- Before an investor / client review, a PCI scan, a SOC 2 audit, or an accessibility-compliance review.
- When a downstream metric drops (rankings, conversion, AI citations) and you need to rule out this dimension as the cause.

## Reading the output

Every finding is severity-classified. The playbook is the same across tools:

- **Critical / red** — same-week fixes. These block the primary signal and cascade into downstream dimensions.
- **Warning / amber** — same-month fixes. Drag the score, usually don't block.
- **Info / blue** — context only. Often what a PR reviewer would flag but that doesn't block merge.
- **Pass / green** — confirmation. Keep the control in place.

Every audit also emits an "AI fix prompt" — paste into ChatGPT / Claude / Gemini for exact copy-paste code patches tied to your specific stack.

## Related tools in this family

- **[Mega Security Analyzer](/tools/mega-security-analyzer/)** — the 7-layer orchestrator — run it first, drill into this tool only if that overall flags a header-category regression.
- **[CSP Strictness Audit](/tools/csp-strictness-audit/)** — sibling audit focused on CSP quality specifically — nonces, hashes, strict-dynamic.
- **[CORS Headers Audit](/tools/cors-headers-audit/)** — ACAO / Vary / Allow-Methods / Max-Age coverage — pair when APIs are in scope.
- **[Subresource Integrity (SRI) Audit](/tools/subresource-integrity-audit/)** — SRI hash presence on every cross-origin script + stylesheet.
- **[Trusted Types Audit](/tools/trusted-types-audit/)** — catches the DOM sinks a hardened CSP would still allow without Trusted Types.

## Fact-check notes and sources

- MDN: [Content Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)
- OWASP: [CORS OriginHeaderScrutiny Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Request_Forgery_Prevention_Cheat_Sheet.html)
- Web.dev: [Secure your site with these response headers](https://web.dev/articles/security-headers)
- Mozilla Observatory: https://observatory.mozilla.org/ (scoring + remediation guidance)

*This post is informational and not a substitute for professional consulting. Mentions of third-party platforms in the tool itself are nominative fair use. No affiliation is implied.*


---

Canonical HTML: https://jwatte.com/blog/blog-tool-api-secret-leakage-audit/
RSS: https://jwatte.com/feed.xml
JSON Feed: https://jwatte.com/feed.json
Hero image: https://jwatte.com/images/blog-tool-api-secret-leakage-audit.webp