ReferenceIntermediate4-6 min reference
Sensitive Data Exposure
Sensitive data exposure is data that should be protected showing up where it shouldn't — in a response body, a log, a URL, or unencrypted in transit. QA can catch a lot of it just by looking, without any attack. This sheet is the where-to-look checklist; for the broader picture see OWASP Top 10 and Security Headers (linked below).
What counts as sensitive
PII (names, emails, addresses), credentials/tokens, payment data (PAN, CVV), health data, internal ids, and anything regulated (GDPR/PCI/HIPAA).
Where it leaks — and how to check
| Location | Check | Should |
|---|---|---|
| Response body | Inspect JSON in DevTools | No password hashes, full PAN, other users' data |
| URLs / query strings | Look at the address bar, referrer | No tokens, ids, or PII in URLs (they're logged) |
| Logs / console | App + browser console | No secrets or full payloads logged |
| Error messages | Trigger errors | No stack traces, SQL, internal paths |
| Storage | localStorage / cookies | Tokens in HttpOnly cookies, not JS-readable storage |
| In transit | Network tab / protocol | HTTPS everywhere; no plaintext HTTP |
| Caching | Response headers | Sensitive responses sent Cache-Control: no-store |
| Masking | UI display | Card/SSN masked (•••• 1234) where shown |
What QA can safely do
Look, read, and report. Confirm masking, HTTPS, HttpOnly, and that responses/logs don't over-share. Don't attempt to decrypt, exfiltrate, or attack — escalate suspected exposure to the security team with evidence.
Common mistakes
- Checking the UI only; the API response often returns more fields than the UI shows.
- Tokens or ids passed in URLs (end up in server logs, history, referrers).
- Verbose error responses leaking internals.
- Sensitive data in
localStorage(readable by any XSS) instead ofHttpOnlycookies. - Masking in the UI while the full value sits in the payload.
// Related resources