Skip to content

CWE-319: Cleartext Transmission of Sensitive Information

Overview

Cleartext transmission occurs when sensitive information is sent over the network without encryption, making it readable to anyone who can intercept the traffic. This includes passwords, session tokens, personal information (SSN, health records), API keys, and payment data transmitted over HTTP instead of HTTPS or other unencrypted channels.

Attackers can easily intercept cleartext data through network sniffing on public WiFi, man-in-the-middle attacks, compromised network infrastructure, or ISP-level interception.

OWASP Classification

A04:2025 - Cryptographic Failures

Risk

Cleartext transmission creates critical security exposures:

  • Credential theft: Usernames and passwords captured by network sniffers
  • Session hijacking: Session cookies stolen and reused for account takeover
  • Privacy violations: Personal information exposed to unauthorized parties
  • Identity theft: SSN, passport numbers, health records intercepted
  • Financial fraud: Credit card numbers and banking credentials compromised
  • Compliance violations: Fails PCI-DSS, HIPAA, GDPR, SOC 2 requirements
  • Business data leakage: Proprietary information and trade secrets exposed
  • API compromise: Authentication tokens for third-party services stolen

Public WiFi networks make these attacks trivial - tools like Wireshark can capture cleartext traffic in seconds.

Remediation Steps

Core principle: Never transmit sensitive data over cleartext channels; require TLS and secure transport.

Locate the cleartext transmission in your application

  • Review the flaw details to identify the specific file, line number, and code pattern
  • Identify what sensitive information is transmitted in cleartext (passwords, session tokens, PII, API keys, credit cards)
  • Trace the data flow: is it using HTTP vs HTTPS, ws:// vs wss://, FTP vs SFTP, plaintext database connections
  • Determine the exposure: can attackers intercept this traffic (public WiFi, ISP level, compromised network)

Use TLS/HTTPS for all communications (Primary Defense)

  • Use HTTPS for entire site: Not just login pages, but all pages handling any data
  • Use TLS 1.2 or higher: TLS 1.3 preferred, disable TLS 1.0, TLS 1.1, SSL 2.0, SSL 3.0
  • Obtain valid certificates: Use trusted CAs (Let's Encrypt is free), avoid self-signed certificates
  • Configure strong cipher suites: Disable weak ciphers (RC4, 3DES, DES, export ciphers)
  • Redirect all HTTP to HTTPS: Use 301 permanent redirects for all HTTP requests
  • Avoid mixed content: Don't mix HTTP and HTTPS resources on same page

Enable HTTP Strict Transport Security (HSTS) and secure cookies

  • Configure HSTS header: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  • Benefits of HSTS: Prevents SSL stripping attacks, blocks accidental HTTP requests, protects on first visit (if preloaded)
  • Secure cookie transmission: Set Set-Cookie: sessionid=...; Secure; HttpOnly; SameSite=Strict
  • Cookie attributes: Secure (HTTPS only), HttpOnly (XSS protection), SameSite (CSRF protection)
  • Mark all authentication cookies: All session cookies must have Secure flag

Encrypt database and backend connections

  • Use TLS/SSL for database connections: PostgreSQL sslmode=require or sslmode=verify-full, MySQL require_secure_transport=ON, MongoDB ssl=true
  • Secure internal APIs: Use HTTPS for service-to-service communication, use mutual TLS (mTLS) for authentication
  • Encrypt message queues: RabbitMQ SSL, Kafka SSL/TLS, Redis TLS
  • Secure file transfers: Use SFTP or SCP (not FTP), use HTTPS for uploads/downloads, encrypt email transport (STARTTLS for SMTP)

Monitor and audit cleartext transmission

  • Review code for HTTP usage (grep for 'http://', 'ws://', plaintext connection strings)
  • Monitor certificate expiration and renewal (SSL certificate monitoring)
  • Log TLS handshake failures and downgrades (detect SSL stripping attempts)
  • Use network monitoring tools to detect cleartext traffic (Wireshark, tcpdump)
  • Scan for mixed content warnings in web applications

Test the TLS/HTTPS implementation thoroughly

  • Verify all HTTP requests redirect to HTTPS (test with curl, browser)
  • Test HSTS header is present (check with browser DevTools, security headers scanner)
  • Verify cookies have Secure flag (inspect Set-Cookie headers)
  • Test TLS configuration with SSL Labs (https://www.ssllabs.com/ssltest/)
  • Use network sniffer to confirm no cleartext sensitive data (Wireshark)
  • Re-scan with security scanner to confirm the issue is resolved

Testing & Verification

Verify HTTPS Enforcement

# Test HTTP request is redirected to HTTPS
curl -I http://yourapp.com
# Expected: 301/302 redirect to https://yourapp.com

# Test HTTPS works
curl -I https://yourapp.com
# Expected: 200 OK with HSTS header

Check HSTS Header

curl -I https://yourapp.com | grep -i strict-transport-security
# Expected: Strict-Transport-Security: max-age=31536000; includeSubDomains

# Check cookies have Secure flag
curl -I https://yourapp.com/login -c cookies.txt
cat cookies.txt
# Expected: All cookies have #HttpOnly and Secure flags

Test TLS Configuration

# Use SSL Labs to test TLS configuration
# https://www.ssllabs.com/ssltest/analyze.html?d=yourapp.com
# Expected: A or A+ rating

# Test with testssl.sh
testssl.sh https://yourapp.com
# Expected: No weak ciphers, TLS 1.2+ only

Network Traffic Analysis

# Capture traffic and verify it's encrypted
tcpdump -i any -A host yourapp.com
# Expected: No readable passwords or sensitive data in output

Mixed Content Check

  • Open browser developer console
  • Navigate to your application
  • Check for mixed content warnings
  • Expected: No warnings about insecure content on secure pages

Additional Resources