Sensitive Data Exposure in Logs in Plaintext

Issue

Sensitive data exposure in logs in plaintext

Impacted Frameworks and Reasons

GDPR (Articles 5 and 32)

• Article 5 requires data minimization, purpose limitation, and integrity. Writing personal data to logs without a valid processing purpose violates these principles.

• Article 32 requires appropriate technical and organizational security measures. Writing personal data to logs in plaintext fails the confidentiality and pseudonymization requirements, especially once those logs are ingested by platforms like Datadog or Splunk.

CCPA and CPRA

• Logs that contain personal data may count as data sharing.

• If users are not informed that their data is logged and transmitted to third parties, this results in undisclosed sharing without required notice or opt out controls.

HIPAA

• PHI must be protected and only shared with authorized business associates.

• Logging PHI into operational monitoring systems without a formal Business Associate Agreement is considered an unauthorized disclosure.

PCI

• Cardholder data must never appear in plaintext outside the controlled PCI environment.

• Logging card data directly violates storage, transmission, and masking requirements.

GLBA

• Requires administrative and technical safeguards for financial data.

• Plaintext logging shows a failure to safeguard customer financial information.

PIPEDA

• Requires meaningful consent for the collection and disclosure of personal data.

• If sensitive data is logged without user awareness, the organization cannot demonstrate consent or proper handling.

APPI

• Requires clear purpose specification and data minimization.

• Logging personal data without necessity breaks purpose limitation and storage minimization rules.

NIST 800 53

• Emphasizes audit control, access restriction, and proper handling of sensitive information.

• Plaintext logs increase exposure risk during retention, ingestion, and access by internal teams.

ISO IEC 29100

• Requires transparency and accountability in handling personal data.

• Excessive or unnecessary logging undermines privacy governance.

KSA PDPL

• Requires lawful basis and explicit consent for processing and transferring personal data.

• Logging personal data into systems that may export data cross border can violate transfer and disclosure controls.

UAE PDPL

• Processing must remain aligned with declared purpose and user expectations.

• Logging personal data beyond operational necessity exceeds authorized processing purpose.

Qatar PDPPL

• Requires safeguards to prevent unauthorized disclosure.

• Plaintext logs increase the likelihood of inadvertent exposure and unauthorized access.

Risk Context

Logs are often ingested into third party monitoring and SIEM platforms such as Datadog and Splunk. Once sensitive data enters these systems, remediation is costly and disruptive. Incidents often require stopping log ingestion, scrubbing retained data, and retroactively fixing the underlying code. This process can take 50 to 100 hours across engineering, privacy, and security teams.

The scanner reports console output separately from application logs, under the Standard Output (stdout) and Standard Error (stderr) data sinks. The same guidance applies to print, console.log, and System.out calls.

CWE and OWASP

This risk maps to CWE-532: Insertion of Sensitive Information into Log File and OWASP Top 10 A09:2021 – Security Logging and Monitoring Failures. The Standard Output and Standard Error sinks map to CWE-209.

Recommended Remediation

Identify locations where sensitive data is written to logs and delete the offending code — the scanner’s remediation strategy for the Logs sink is deletion. Where the value must remain, pass it through a sanitizer so the dataflow is marked safe. Confirm that no sensitive fields are included in debug or trace level logs. Verify that log data flowing to external observability platforms is limited to operational metadata only and aligns with the stated privacy notice and contractual data processing agreements.