Sensitive Data Exposure

Also Known As

TL;DR

Explanation

Sensitive data exposure covers any case where confidential information is accessible beyond its intended audience — logged passwords, stack traces with database credentials in error pages, session tokens in URLs, unencrypted fields in a database, or API keys committed to source control. Mitigation requires classifying sensitive fields, scrubbing them from logs, using HTTPS everywhere, encrypting at rest, and auditing what appears in error output.

Common Misconception

Why It Matters

Common Mistakes

• Logging passwords, tokens, or full credit card numbers in application or access logs.
• Sending sensitive data in URL query strings which appear in server logs and browser history.
• Returning full user objects from APIs including hashed passwords, internal IDs, or admin flags.
• Storing unencrypted PII in session data or client-side cookies.

Code Examples

// Logging sensitive fields
\$logger->info('Payment', ['card_number' => \$card, 'cvv' => \$cvv]);

// Returning full model in API response
return response()->json(User::find(\$id)); // includes password_hash, SSN...

// PHP 8.2 — #[SensitiveParameter] redacts value in stack traces
function charge(#[\SensitiveParameter] string \$cardNumber): void {}

// API resources — explicit allowlist
class UserResource extends JsonResource {
    public function toArray(\$request): array {
        return [
            'id'    => \$this->id,
            'name'  => \$this->name,
            'email' => \$this->email,
            // password_hash, ssn never included
        ];
    }
}

// Encrypt sensitive fields at rest
\$ssn = Crypt::encryptString(\$rawSsn);

// php.ini production:
// display_errors = Off
// expose_php     = Off

References

• ↗ https://owasp.org/www-project-top-ten/2021/A02_2021-Cryptographic_Failures
• ↗ https://cwe.mitre.org/data/definitions/200.html

Tags

Related Terms