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

v4 ID	v4 Requirement	v5 ID	v5 Equivalent (summary)
7.1.1	Do not log credentials or payment details; hash session tokens.	16.2.5	Logging of sensitive data is enforced according to the data’s protection level — some data may not be logged at all, and some only hashed or masked.
7.1.2	Do not log other sensitive data as defined by local privacy law or policy.	16.2.5	Merged into the same protection-level requirement as 7.1.1.
7.1.3	Log security-relevant events (auth, access control, deserialization failures).	16.3.1, 16.3.2, 16.3.3	Log authentication operations, failed authorization attempts, and the documented security events.
7.1.4	Each log event includes information for a detailed investigation timeline.	16.2.1	Each log entry includes necessary metadata (when, where, who, what).
7.4.1	Generic error messages; do not disclose sensitive information in errors.	16.5.1	A generic message is returned to the consumer, with no exposure of stack traces, queries, secret keys, or tokens.

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. The HIPAA Security Rule makes encryption of PHI at rest and in transit an addressable implementation specification, requiring encryption or a documented equivalent safeguard. PCI DSS v4.x Requirement 3.5.1 requires that PAN be rendered unreadable anywhere it is stored, including logs. Logging sensitive data in cleartext creates direct exposure under 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):

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);
    }
}

const winston = require('winston');
const logger = winston.createLogger({ transports: [new winston.transports.Console()] });

function logLoginAttempt(username, success) {
  // Log only non-sensitive fields
  logger.info('Login attempt', { username, success });
  // NEVER: logger.info('Login', { username, password });
}

import logging

logger = logging.getLogger('auth')

def log_login_attempt(username: str, success: bool) -> None:
    # Log only non-sensitive fields
    logger.info("Login attempt: user=%s success=%s", username, success)
    # NEVER: logger.info("Login: user=%s password=%s", 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.

import org.apache.commons.codec.digest.DigestUtils;

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 maskId(String id) {
        return DigestUtils.sha256Hex(id).substring(0, 12);
    }
}

const crypto = require('crypto');

function maskEmail(email) {
  if (!email || !email.includes('@')) return '***';
  const [local, domain] = email.split('@');
  if (local.length < 2) return `***@${domain}`;
  return `${local[0]}***@${domain}`;
}

function maskId(value) {
  return crypto.createHash('sha256').update(value).digest('hex').slice(0, 12);
}

import hashlib

def mask_email(email: str) -> str:
    if not email or "@" not in email:
        return "***"
    local, domain = email.split("@", 1)
    if len(local) < 2:
        return f"***@{domain}"
    return f"{local[0]}***@{domain}"

def mask_id(value: str) -> str:
    return hashlib.sha256(value.encode()).hexdigest()[: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, Python logging, winston, bunyan, pino, log4js) and log aggregation platforms (OpenTelemetry, AWS CloudWatch, Azure Log Analytics, Logz.io). Observability SDKs such as Datadog, Sentry, and New Relic are tracked separately as third-party data sinks under CWE-201.
Sanitizer recognition. If sensitive data passes through a recognized sanitizer before reaching the log, the scanner does not flag it — reducing false positives. By default the scanner recognizes functions named anonymize/ anonymise, encrypt, mask, obfuscate, redact, or sanitize, optionally followed by _ or an uppercase letter and more characters (for example maskEmail or redact_ssn). Add your own patterns under Sanitizers if your helpers are named differently.
PR-level enforcement. Violations surface in scans of 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.

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.