A04:2025 - Cryptographic Failures

Cryptographic Failures holds position four in the OWASP Top 10 for 2025, moving down from A02 in the 2021 edition. Previously titled "Sensitive Data Exposure," the category was renamed to focus on the root cause rather than the symptom: the cryptographic weaknesses that lead to data exposure. As regulatory requirements around data protection tighten globally and the volume of sensitive data in transit and at rest continues to grow, proper cryptographic implementation is more critical than ever.

Overview

Cryptographic failures occur when applications use weak algorithms, mismanage keys, transmit data without encryption, or generate predictable values where randomness is required. The consequences range from exposure of passwords and personal data to complete compromise of encrypted communications. These failures are particularly dangerous because they are often silent: an application using MD5 to hash passwords or ECB mode to encrypt data will function correctly while providing a false sense of security. Radar's SAST engine identifies cryptographic anti-patterns in source code, catching weak algorithms, hardcoded secrets, and missing protections before they reach production.

What Radar Detects

• Weak hashing algorithms. Use of MD5 or SHA-1 for password hashing, data integrity verification, or digital signatures. These algorithms have known collision attacks and are considered cryptographically broken for security purposes.

• Insecure encryption algorithms and modes. Use of DES, 3DES, RC4, or Blowfish for encryption, as well as ECB mode with any block cipher. ECB mode preserves patterns in plaintext, and the legacy algorithms have key sizes or structures that are vulnerable to modern attacks.

• Hardcoded encryption keys and secrets. Cryptographic keys, API secrets, initialization vectors, and salts embedded directly in source code or configuration files. Hardcoded keys cannot be rotated without a code change and are exposed to anyone with repository access.

• Missing TLS enforcement. HTTP endpoints that do not redirect to HTTPS, mixed content loading insecure resources over HTTP within HTTPS pages, and missing HSTS headers that leave users vulnerable to protocol downgrade attacks.

• Insufficiently random values. Use of non-cryptographic random number generators for security-sensitive operations, such as Math.random() in JavaScript, java.util.Random in Java, or rand() in C/C++ for generating tokens, session IDs, or nonces.

• Cleartext transmission of sensitive data. Passwords, tokens, or session identifiers sent without encryption, including cookies missing the Secure flag that may be transmitted over unencrypted connections.

• Weak key derivation. Passwords hashed with simple algorithms (plain SHA-256, unsalted hashing) instead of dedicated key derivation functions designed to resist brute-force attacks like PBKDF2, bcrypt, or Argon2.

Related CWEs

CWE-327 (Use of a Broken or Risky Cryptographic Algorithm), CWE-330 (Use of Insufficiently Random Values), CWE-798 (Use of Hardcoded Credentials), CWE-311 (Missing Encryption of Sensitive Data).

See the CWE Reference for details.

Prevention

• Use AES-256-GCM or ChaCha20-Poly1305 for symmetric encryption. Avoid ECB mode entirely and prefer authenticated encryption modes that provide both confidentiality and integrity.
• Use SHA-256 or SHA-3 for data integrity and digital signatures. Never use MD5 or SHA-1 for any security-related purpose.
• Hash passwords exclusively with bcrypt, scrypt, or Argon2 with appropriate work factors. Never use general-purpose hash functions for password storage.
• Never hardcode cryptographic keys, secrets, or initialization vectors in source code. Use a dedicated secret management service and inject secrets at runtime through environment variables or secure vaults.
• Enforce HTTPS across the entire application with HSTS headers (including includeSubDomains and preload directives) and ensure all cookies carry the Secure flag.
• Use cryptographically secure pseudorandom number generators (CSPRNG) for all security-sensitive random values: crypto.getRandomValues() in browsers, secrets module in Python, SecureRandom in Java, or RandomNumberGenerator in .NET.
• Implement a key rotation policy and design your encryption architecture to support key rotation without data loss or downtime.
• Classify data by sensitivity and apply encryption requirements proportional to the risk level.

Next Steps