Skip to content

CWE-359: Exposure of Private Personal Information to an Unauthorized Actor

Overview

Privacy violations occur when applications expose PII (names, SSN, medical data, financial info) through logs, error messages, APIs, URLs, or insufficient access controls, violating GDPR/CCPA/HIPAA and enabling identity theft, fraud, and legal liability.

OWASP Classification

A01:2025 - Broken Access Control

Risk

High: PII exposure enables identity theft, financial fraud, privacy violations, regulatory fines (GDPR €20M/$4%), HIPAA violations ($50k per record), discrimination, stalking, and reputational damage.

Remediation Steps

Core principle: Minimize and control access to personal data; enforce authorization and least disclosure for PII everywhere.

Locate the PII exposure in your application

  • Review the flaw details to identify the specific file, line number, and code pattern where PII is exposed
  • Identify what PII is being exposed: names, SSN, medical data, financial info, addresses, phone numbers, email addresses
  • Determine the exposure channel: logs, error messages, APIs, URLs, database queries, analytics, UI display
  • Trace the data flow to understand where PII goes from collection to exposure

Minimize PII collection and retention (Primary Defense)

  • Collect only necessary PII: Don't collect data you don't need; question every PII field in forms
  • Delete PII when no longer needed: Implement data retention policies (delete after 90 days, 1 year)
  • Use data retention policies: Automated purging of old PII, scheduled deletion jobs
  • Anonymize analytics data: Hash or aggregate PII before sending to analytics (Google Analytics, Mixpanel)

Implement proper access controls

  • Role-based access control (RBAC): Only users with "view_pii" role can access PII fields
  • Verify user authorization before exposing PII: Check permissions before returning PII in API responses
  • Separate PII access from other data: Require additional authentication (re-enter password) for PII access
  • Audit PII access: Log who accessed what PII and when (for GDPR/HIPAA compliance)

Protect PII in transit and at rest

  • Encrypt PII in databases: Use database-level encryption or application-level encryption (AES-256) for PII columns
  • Use TLS for transmission: Always use HTTPS for any page or API endpoint that handles PII
  • Mask/redact PII in logs: Don't log SSN, credit cards, passwords; redact them (XXX-XX-1234) or omit entirely
  • Tokenize credit cards/SSN: Replace with tokens (tok_4242424242424242) instead of storing actual values

Avoid PII leakage

  • Don't log PII (SSN, passwords, credit cards): Never log sensitive PII even in debug logs
  • Don't expose PII in URLs: Use POST requests, not GET with PII in query parameters (/user?ssn=123-45-6789)
  • Redact PII in error messages: Don't include PII in stack traces or error messages
  • Don't include PII in analytics: Anonymize or hash PII before sending to analytics platforms
  • Mask PII in UI (show last 4 digits): Display XXX-XX-1234 instead of full SSN, * **** 4242 for credit cards

Test the PII protection fix

  • Verify PII is not logged (search logs for SSN patterns, credit card patterns)
  • Verify PII is not in URLs (check URL parameters, browser history)
  • Test API responses filter PII based on user permissions
  • Verify PII is encrypted in database (inspect database to see ciphertext, not plaintext)
  • Test masking in UI (verify only last 4 digits shown)
  • Re-scan with security scanner to confirm the issue is resolved

Common Vulnerable Patterns

  • SSN/credit cards in logs
  • PII in URL parameters
  • Returning all user data without filtering
  • PII in error messages/stack traces
  • Unencrypted PII in databases

Additional Resources