Sensitive Data Exposure
// Definition
Leaking private or confidential data — passwords, tokens, personal data, payment-card data or internal details — through responses, logs, error messages, tokens or insecure storage. It is one of the most common high-impact issues QA can catch: confirm that sensitive values are masked in the UI and API responses, are not present in JWT payloads, and do not appear in stack traces. When reporting, mask the values themselves so the bug report does not become a second exposure.
// Related terms
Audit Log
A tamper-resistant record of important system and user actions — who did what, to what, and when. Audit logs support detection, investigation and accountability, especially for sensitive actions like role changes, deletions, admin operations and failed logins. For QA, the check is simple but often missed: perform a sensitive action and confirm a corresponding audit-log entry exists with the actor, action and timestamp.
Security Headers
HTTP response headers that instruct the browser to apply protective behaviour — for example Content-Security-Policy (limits where scripts can load from), Strict-Transport-Security (forces HTTPS), X-Content-Type-Options and X-Frame-Options (limits framing/clickjacking). They are a cheap, high-value defence layer. QA can inspect responses in the browser network panel or an API tool and flag missing or misconfigured headers on key pages.
JWT
JSON Web Token — a compact, URL-safe token format for transmitting claims between parties. A JWT has three Base64URL-encoded sections separated by dots: header (signing algorithm), payload (claims like `sub`, `exp`, `roles`), and signature. Because the payload is encoded but not encrypted, any holder of the token can read the claims — never store secrets in a JWT payload. Test JWTs by checking expiry enforcement, algorithm validation (reject `alg: none`), and rejection of tampered signatures.