Cryptographic failures: the category no request reveals

Figures are from the A04:2025 page of the OWASP Top 10.

OWASP describes the category as the lack of cryptography, cryptography too weak for the job, leaked keys, and the errors around them.

• Data sent without encryption. Or without the extra application-level protection some data needs.
• Old or weak algorithms and protocols. Left on by default or kept in legacy code.
• Poor key management. Default, weak or reused keys, no rotation, keys committed to repositories.
• Encryption not enforced. For example, because the security headers that require HTTPS are missing.
• Certificates not validated. The server certificate or its chain of trust is accepted without checking.
• Weak password storage. Fast or unsalted hashes, or passwords used directly as keys.
• Weak randomness and deprecated hashes. Generators not built for cryptography; MD5 or SHA-1 where a modern hash is needed.
• Downgrade and side channels. An algorithm that can be negotiated down, or error messages that leak information, such as a padding oracle.

A request filter reads requests on their way to the application. Most of this category concerns things that happen elsewhere: data at rest in a database, a hash computed when a password is saved, a key in a repository, a certificate check made when the application calls another service.

OWASP's two scenarios make the point. In the first, a site that does not enforce TLS lets an attacker on the same network downgrade a visitor's connection and steal the session cookie; the attack happens between the visitor and the site, before any filter sees a request. In the second, a password table stored with fast, unsalted hashes is exposed through a separate flaw and cracked offline.

Neither attack sends the site a request that looks like an attack.

OWASP's list is long; the core of it fits in five lines.

1. Know which data is sensitive. Classify it, keep less of it, and discard it early.
2. Encrypt it in transit and at rest. TLS 1.2 or later with forward secrecy, HTTPS enforced with HSTS, and sensitive data encrypted where it is stored.
3. Use current, well-established implementations. Authenticated encryption, proper modes and initialisation vectors, and no MD5, SHA-1 or other deprecated functions.
4. Hash passwords slowly. With a salted, adaptive function that has a work factor, such as Argon2, scrypt or PBKDF2.
5. Manage keys. Generated with secure randomness, rotated, kept out of repositories, and the most sensitive ones held in a hardware or cloud security module.

OWASP also asks that responses carrying sensitive data are not cached, including by CDNs, and that high-risk systems are prepared for post-quantum cryptography by the end of 2030.

Transport encryption is the one part of the category that sits at the edge of a site. Certificates, protocol versions and HTTPS enforcement are decided where the connection terminates, which is why they belong to the certificate layer of a CDN. That is a different component from request filtering, and enabling one does not configure the other.