CWE-210: Self-generated Error Message Containing Sensitive Information - Remediation

Introduction

CWE-210: Self-generated Error Message Containing Sensitive Information occurs when the product identifies an error condition and creates its own diagnostic or error messages that contain sensitive information. When that output includes Personally Identifiable Information (PII), the risks of misuse are significantly heightened.

This article discusses the risks associated with PII exposure through CWE-210 and provides remediation techniques, along with coding examples in Java, JavaScript, and Python.

Note

HoundDog.ai does not report CWE-210 directly. Sensitive data reaching the Standard Output and Standard Error sinks is reported as CWE-209, and data reaching application logs as CWE-532. This page is included as related background.

Understanding the Risks

Direct Risks

1. Identity Theft: Exposure of personal identifiers can lead directly to identity theft.

2. Fraud: Exposed financial information, like credit card numbers or account details, can lead to fraudulent transactions.

3. Unauthorized Access: Sensitive information such as passwords or security answers can be used to gain unauthorized access to systems.

Indirect Risks

1. Reputational Damage: Incidents of PII exposure can harm the organization’s reputation, potentially leading to customer loss.

2. Regulatory Penalties: Non-compliance with data protection laws (GDPR, HIPAA, etc.) can result in significant fines.

3. Operational Distractions: Managing the fallout from a data breach can consume significant time and resources.

Remediation Techniques

Mitigating the risk of PII exposure in self-generated information involves careful management of what data is included in output streams. Techniques include omitting unnecessary data, masking sensitive details, and encrypting outputs to secure potentially sensitive information.

1. Omitting Data

Avoid logging sensitive data unless absolutely necessary.

Java

public class LogUtility {
    public void logMessage(String message) {
        // Ensure that no sensitive PII is logged
        System.out.println("Log: " + message);
    }
}

Javascript

function logMessage(message) {
    // Avoid logging sensitive PII
    console.log("Log:", message);
}

Python

def log_message(message):
    # Do not log sensitive PII
    print(f"Log: {message}")

2. Masking Data

If data must be included in logs or other outputs, ensure it is sufficiently masked.

Java

public class User {
    public String maskEmail(String email) {
        int atIndex = email.indexOf("@");
        return email.substring(0, 1) + "****" + email.substring(atIndex - 1);
    }
}

Javascript

function maskEmail(email) {
    const atIndex = email.indexOf('@');
    return email[0] + '****' + email[atIndex - 1] + email.substring(atIndex);
}

Python

def mask_email(email):
    atIndex = email.index('@')
    return email[0] + '****' + email[atIndex - 1] + email[atIndex:]

3. Encrypting Data

When storing or transmitting data that could be logged or intercepted, use encryption.

Java

import javax.crypto.Cipher;
import javax.crypto.SecretKey;
import javax.crypto.spec.GCMParameterSpec;
import java.nio.ByteBuffer;
import java.nio.charset.StandardCharsets;
import java.security.SecureRandom;

public class EncryptionUtility {
    // secretKey is supplied by the caller, sourced from your KMS or secret store
    public static String encrypt(String data, SecretKey secretKey) throws Exception {
        byte[] iv = new byte[12];
        new SecureRandom().nextBytes(iv);

        Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
        cipher.init(Cipher.ENCRYPT_MODE, secretKey, new GCMParameterSpec(128, iv));
        byte[] encrypted = cipher.doFinal(data.getBytes(StandardCharsets.UTF_8));

        byte[] payload = ByteBuffer.allocate(iv.length + encrypted.length).put(iv).put(encrypted).array();
        return java.util.Base64.getEncoder().encodeToString(payload);
    }
}

Javascript

const crypto = require('crypto');

// key: 32-byte Buffer loaded from your KMS or secret store
function encrypt(data, key) {
    const iv = crypto.randomBytes(16);
    const cipher = crypto.createCipheriv('aes-256-cbc', key, iv);
    const encrypted = Buffer.concat([cipher.update(data, 'utf8'), cipher.final()]);
    return iv.toString('hex') + ':' + encrypted.toString('hex');
}

Python

from cryptography.fernet import Fernet

# key: Fernet key loaded from your secret store, never generated per call
def encrypt(data, key):
    cipher = Fernet(key)
    encrypted = cipher.encrypt(data.encode())
    return encrypted.decode()

Detecting this with HoundDog.ai

HoundDog.ai’s Privacy Code Scanner (hounddog scan) does not report CWE-210 directly. Sensitive data that reaches the standard output and standard error streams is reported as CWE-209, and sensitive data that reaches application logs is reported as CWE-532.

• Sensitive data types. The scanner ships with over 100 data element definitions covering common PII, PHI, CHD, PIFI, and secret data (tags PII, PHI, CHD, PIFI, SECRET); the full list is in the scanner’s data-elements.md. A finding names the data element involved, such as Email or Social Security Number.

• Sinks. The Standard Output (stdout) and Standard Error (stderr) data sinks are reported as CWE-209. The Logs sink, along with the AWS CloudWatch, Logz.io, and OpenTelemetry sinks, is reported as CWE-532.

• Languages. Dataflows are reported for Python, JavaScript, TypeScript, Java, C#/.NET, and Go. Other supported languages are scanned for data elements only and produce no dataflows. See Supported Languages.

• Sanitization. When AI dataflow reviews are enabled, each dataflow is reviewed with its code and trace in context, including any sanitization logic (masking, hashing, encryption, redaction) applied before the data reaches the sink. Dataflows where the data is effectively sanitized are marked as false positives.

For example, scanning a Python file that prints a user’s email address produces a CWE-209 finding like this (console output, excerpt; the file path is shortened):

print(f"Failed to process {user.email}")

🟨  LOW: Email sent to Standard Output in /path/to/project/app.py:2:5

  2 │ print(f"Failed to process {user.email}")

Associated Compliance Frameworks
────────────────────────────────
CWE: CWE-1295, CWE-209
OWASP: A04:2021
Privacy: CCPA, GDPR-A5-32, NIST-800-53

To run a scan, see the quickstart. For how data elements and data sinks are defined and customized, see the scanner rules reference.

Conclusion

To effectively manage CWE-210 risks, developers and system administrators must be vigilant in controlling the content of output generated by applications, especially when handling PII. Implementing practices such as omitting, masking, and encrypting sensitive data can greatly reduce the likelihood of inadvertent exposure. This ensures compliance with privacy laws and helps maintain trust and security.