OWASP ASVS 7.1.1: Logging Sensitive Data and PII - Remediation Guide

Introduction

OWASP ASVS requirement 7.1.1 is part of the Application Security Verification Standard's V7 chapter on error handling and logging. It states that applications must not log credentials, session tokens, or payment details - and that any sensitive data written to logs must be appropriately protected. This requirement exists because logs are frequently the weakest link in an application's security posture: they are copied, forwarded to observability platforms, archived, and accessed by engineers who do not otherwise have permission to view production data.

For privacy-conscious engineering teams, 7.1.1 is also a direct overlap point with GDPR, HIPAA, and CCPA obligations. Logging personal data without a lawful basis, proper minimization, or adequate protection can constitute an unauthorized processing activity even if the log file never leaves the company.

The requirement, in OWASP's words

ASVS v4.0.3: 7.1.1 Verify that the application does not log credentials or payment details. Session tokens should only be stored in logs in an irreversible, hashed form.

ASVS 5.0, released in May 2025, restructured chapter numbering. Teams already migrating to v5 should use the mapping below.

ASVS v4 → v5 mapping for logging requirements

Why this requirement exists: understanding the risks

Direct risks. Log files are high-value targets because they concentrate sensitive data in one place and are often less protected than the application database. A single compromised log volume can expose millions of records. In the 2019 Facebook password logging incident, cleartext passwords for hundreds of millions of users were stored in plain text in internal logs, accessible to thousands of employees - a textbook 7.1.1 violation.

Regulatory risks. GDPR Article 32 requires appropriate technical measures to protect personal data. HIPAA Security Rule requires encryption of PHI at rest and in transit, including in logs. PCI DSS Requirement 3.4 prohibits storing full PAN data unrecoverable. Logging sensitive data in cleartext creates direct violations of all three.

Indirect risks. Logs are frequently shipped to third-party observability platforms (Datadog, Sentry, Splunk, New Relic). Sensitive data in logs extends a Data Processing Agreement obligation to each downstream processor, expanding the compliance surface area. Logs also escape standard data-retention policies because most organizations retain logs far longer than they retain application data.

Remediation: three patterns

Preventing sensitive data from reaching logs comes down to three patterns, in order of preference: omission, masking, and encryption.

1. Omit sensitive data from logs entirely

The safest option is not to log sensitive data at all. Identify which fields are sensitive (passwords, tokens, SSNs, credit card numbers, full names, email addresses, government IDs, health data, financial data) and exclude them from log statements.

Java (SLF4J):

xxxxxxxxxx

import org.slf4j.Logger;

import org.slf4j.LoggerFactory;

public class AuthLogger {

    private static final Logger logger = LoggerFactory.getLogger(AuthLogger.class);

    public void logLoginAttempt(String username, boolean success) {

        // Log only non-sensitive fields

        logger.info("Login attempt: user={} success={}", username, success);

        // NEVER: logger.info("Login: user={} password={}", username, password);

    }

}

HoundDog.ai: HoundDog.ai's Privacy Code Scanner detects this pattern automatically by tracing sensitive data types (PII, PHI, CHD, credentials) from their source through the code and flagging when they reach logging sinks. See the scanner's CWE-532 and CWE-209 detections for the exact code patterns matched.

2. Mask or tokenize when partial data must be logged

When some form of the data is required for debugging or audit (e.g., to correlate log entries to a specific user), replace the sensitive value with a masked, hashed, or tokenized representation.

xxxxxxxxxx

public class DataMasker {

    public static String maskEmail(String email) {

        if (email == null || !email.contains("@")) return "***";

        int atIndex = email.indexOf('@');

        if (atIndex < 2) return "***" + email.substring(atIndex);

        return email.charAt(0) + "***" + email.substring(atIndex - 1);

    }

    public static String hashId(String id) {

        return DigestUtils.sha256Hex(id).substring(0, 12);

    }

}

3. Encrypt when sensitive data must be preserved in logs

Rare, but sometimes required — for example, when audit logs must retain complete payload detail for regulatory review. In these cases, encrypt at the logging layer with a key managed separately from the log storage.

Warning: Do not invent cryptography. Use your platform's standard envelope-encryption library (AWS KMS, Google Cloud KMS, HashiCorp Vault Transit) with a rotation policy. Never store encryption keys in the same system as the encrypted logs — that defeats the purpose.

How HoundDog.ai automates ASVS 7.1.1 verification

Manual ASVS audits ask developers to demonstrate that logs don't contain sensitive data. This usually means grepping log files in staging, reviewing logging statements in code, and interviewing engineers about what they pass to loggers. HoundDog.ai replaces this with static, code-level verification that runs in CI before code ships.

• ** Data flow tracing. The scanner identifies sensitive data at the source (database models, API request bodies, third-party SDK outputs) and traces it through function calls, assignments, and transformations to detect when it reaches a logger.
• *
• Sink coverage. Logging sinks include standard libraries (slf4j, logback, log4j, logging, winston, bunyan, pino), cloud observability SDKs (Datadog, Sentry, New Relic), and custom log wrappers defined in your codebase.
• Sanitizer recognition. If sensitive data passes through a recognized sanitizer (your maskEmail function, a hashing helper, an encryption wrapper) before reaching the log, the scanner does not flag it — reducing false positives.
• PR-level enforcement. Violations surface as comments on the pull request that introduced them, with a data flow trace showing exactly how sensitive data reached the logger. CI pipelines can be configured to block merges on unresolved findings.

Related ASVS requirements in V7 (v4) / V16 (v5)

Requirement 7.1.1 is part of a cluster of related logging requirements. Teams implementing secure logging should address these together:

• **

7.1.2 - Other sensitive data. **Expands the prohibition beyond credentials and payment data to any data classified as sensitive under local privacy law (GDPR personal data, HIPAA PHI, CCPA personal information) or organizational policy.

• 7.1.3 - Security event logging. Requires logging of authentication events, access control failures, deserialization failures, and input validation failures - the flip side of 7.1.1 (what you must log, versus what you must not).
• 7.1.4 - Log event completeness. Each log event must contain enough information to support detailed forensic investigation: timestamp, source IP, user identifier, action, outcome.
• 7.4.1 - Error message handling. Prevents sensitive information disclosure through error messages returned to users or written to logs. Covered on our dedicated OWASP ASVS 7.4.1 page.

Common mistakes we see in code

Our scanner sees thousands of real-world logging mistakes per quarter across customer codebases. The most frequent patterns:

• ** Logging the full request or response object. logger.info("Received: {}", request) writes everything, including auth headers, body payloads, and cookies. Log specific, non-sensitive fields instead.
• *
• Logging exceptions that wrap sensitive input. A validation error for a credit card field often includes the offending value in the exception message. logger.error("Validation failed", ex) then serializes the card number into logs.
• Debug-level logging that leaks in production. Debug logs are frequently written with far less care than info/warn/error logs, under the assumption they won't run in production — until someone flips a log level flag during an incident.
• Third-party SDKs that log internally. HTTP client libraries and database drivers sometimes log request/response bodies for debugging. These logs bypass your application's logging policy entirely.
• AI/LLM prompt logging. Applications using OpenAI, Anthropic, or other LLM APIs often log the full prompt for debugging. If prompts contain user data, this creates new exposure paths the privacy team was never informed about.

Frequently asked questions

What counts as sensitive data under ASVS 7.1.1?

The requirement explicitly names credentials, session tokens, and payment details. In practice, teams should extend this to any data defined as sensitive by GDPR (personal data), HIPAA (PHI), PCI DSS (cardholder data), or internal data classification policy — including government IDs, health information, precise geolocation, and authentication secrets.

Does ASVS 7.1.1 prohibit logging session IDs?

Not entirely. The requirement allows session tokens in logs only if stored in an irreversible hashed form. Raw session tokens are prohibited because they can be replayed to hijack an active session.

How does ASVS 7.1.1 relate to CWE-532?

CWE-532 (Insertion of Sensitive Information into Log File) is the weakness class that ASVS 7.1.1 is designed to prevent. ASVS defines the verification requirement; CWE defines the underlying software weakness. Detecting CWE-532 in code is evidence of a potential ASVS 7.1.1 violation.

Can I log anonymized or pseudonymized data?

Yes, provided the anonymization is robust. Masked emails (j***@example.com), hashed identifiers, and tokenized values that cannot be reversed to the original sensitive value are acceptable. Simple redaction that leaves parts of the original value recoverable (e.g., last-four-digits of a card combined with other log fields) may not be sufficient.