How to detect PII exposure in code, logs & third-party scripts
Privacy gaps usually start in code, not after launch. PII and secrets leak through hardcoded API keys in JavaScript bundles, over-broad API responses, PII written to application logs, sensitive data in local storage, and silent third-party or AI integrations that receive fields your privacy notice never disclosed (HoundDog.ai — privacy code scanning; SUSA — data exposure in logs). Detection is a discipline with repeatable methods and tools; this guide maps them. First, be clear on what counts as PII.
1. Where PII actually leaks
- Source code & config — API keys, tokens, credentials (e.g.,
AKIA[0-9A-Z]{16},ghp_...,xoxb-...) committed to repos or shipped in client bundles. - Logs & crash reporters — full user objects, emails, SSNs, auth tokens printed via
Log.dor sent to Crashlytics. - API responses — endpoints returning more fields than the client needs (data over-exposure).
- Local storage / SharedPreferences — PII cached unencrypted on device.
- Third-party & AI scripts — analytics, pixels, or LLM prompts silently receiving PII with no DPA or legal basis.
2. Detection methods
| Method | What it catches | Example tooling |
|---|---|---|
| Static pattern scan | SSN, card, email, phone, key formats in code/config | truffleHog, gitleaks, pii-detector |
| Dynamic intercept | PII in request/response bodies over the wire | OWASP ZAP, Burp Suite |
| Log inspection | PII in log files / streams via regex | custom regex, PII Detector libs |
| Privacy code scanning | Sensitive data flows across functions, APIs, 3P, AI | HoundDog.ai-style scanners |
| Manual code review | Context false positives miss | checklist + peer review |
Regular-expression patterns are the workhorse: SSN \b\d{3}-\d{2}-\d{4}\b, emails, US phone \b\d{3}[-.]?\d{3}[-.]?\d{4}\b, AWS AKIA[0-9A-Z]{16}, GitHub ghp[0-9a-zA-Z]{36} (pii-detector skill; truffleHog; gitleaks; OWASP ZAP).
3. Build it into the pipeline
Shift detection left: run secret and PII scanners in CI on every PR, scan git history (not just the working tree), intercept traffic in a staging proxy, and add log-redaction utilities so PII never reaches disk. Enforce a checklist requiring every log statement to redact or use a safe logger. The goal is to catch exposure before release, not after a complaint.
4. Limits of automated detection
Pattern matching has false positives (a fake SSN in a test) and false negatives (a name that isn't in a dictionary). Context — is this field actually tied to a person in your system? — still needs human judgement, and detection is not the same as a lawful basis. Findings should feed your data inventory and your breach prevention plan.
Decision-support note. PrivScan surfaces likely PII exposure on a live site or app — trackers, forms, and third-party scripts that collect or transmit personal data — and returns a prioritized checklist. It is a scanner, not a code auditor, and does not replace a qualified review or a formal DPIA.