Missing Encryption of Sensitive Data

Sensitive data is transmitted or stored without encryption where encryption should be the baseline expectation - plaintext HTTP for anything carrying credentials or PII, unencrypted database fields for sensitive records, or unencrypted backups and exports. The common failure isn't choosing the wrong algorithm (that's the broken-cryptographic-algorithm category); it's that no encryption was applied at all where the data's sensitivity called for it.

Data-at-rest encryption (database, backups, exports) is invisible from outside the application entirely. Data-in-transit is partially observable - whether a connection uses HTTPS at all is externally checkable - but that narrower slice is already covered by TLS/header auditing rather than this broader storage-and-transit category.

For the externally observable transit slice, checking whether HTTPS and HSTS are correctly required covers most of what can be confirmed from outside. For data at rest, infrastructure and database configuration review is needed.

Tip: Source-level cryptographic review — checking library usage, mode selection, IV/nonce generation, and key management against known-good patterns — is the standard way these are caught, ideally by someone with applied-cryptography experience rather than general code review, since a broken implementation and a correct one produce identical-looking ciphertext from outside.

Real-World Impact

This family covers cryptographic implementation mistakes that don't fit one of the more specific named categories: using a correct algorithm with a subtly wrong mode (ECB instead of CBC/GCM), a static or predictable IV/nonce, insufficient key length, a missing verification step in a protocol, or a home-grown scheme instead of a vetted primitive. The common thread across all of them is that the mistake usually looks identical to a correct implementation from outside — the same ciphertext-shaped bytes come back either way — so the flaw only becomes visible when you know how the encryption is actually implemented, not just that encryption is happening at all.

The practical consequences range from an attacker being able to distinguish or manipulate ciphertext (a broken mode or reused nonce can leak plaintext relationships or allow forgery) to full recovery of encrypted data (a weak algorithm, insufficient key length, or a completely broken home-grown scheme). Missing or incomplete verification steps, like an incomplete signature check, can additionally let an attacker forge data the application trusts as authentic.

Because these bugs are invisible from outside the implementation, they persist far longer on average than input-validation bugs — a broken cryptographic scheme frequently ships and stays in production for years before a code-level review or an academic cryptanalysis surfaces it.

Prevention and Secure Design

Preventing Missing Encryption of Sensitive Data takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Use vetted, high-level cryptographic libraries — never build a custom scheme. A well-reviewed library's default, recommended API (not its low-level primitives used incorrectly) is dramatically safer than any custom construction, however simple the requirement seems.

Use authenticated encryption modes. Prefer AEAD modes (AES-GCM, ChaCha20-Poly1305) over unauthenticated modes like ECB or plain CBC, which don't protect integrity and are vulnerable to a range of well-known attacks.

Generate IVs and nonces correctly, every time. A nonce must never repeat under the same key — use the library's recommended generation method rather than a fixed or predictable value.

Keep key lengths and algorithm choices current. Cryptographic recommendations shift as computational power and cryptanalysis advance — periodically re-validate algorithm and key-length choices against current guidance rather than what was correct when the code was written.

Have cryptographic code reviewed by someone with applied-cryptography experience. General code review reliably misses subtle mode, IV, or verification-step mistakes that a cryptography-focused reviewer catches immediately.