Why AES-CBC fails in modern web apps and how AES-GCM fixes it with authenticated encryption

A technical guide published on dev.com competitor dev.to walks through one of the most common cryptographic mistakes still present in web codebases: using AES in Cipher Block Chaining (CBC) mode in situations where an attacker can tamper with ciphertext. The piece argues that a 256-bit key means little when the mode of operation offers no integrity protection, and it sets out both the attack mechanics and the AES-GCM alternative.

What CBC mode actually does

AES is a block cipher, standardized in NIST FIPS 197, that encrypts fixed 16-byte blocks using a 128-, 192-, or 256-bit key. Because real payloads are rarely an exact multiple of 16 bytes, a mode of operation has to bridge the gap. In CBC mode, each plaintext block is XORed with the previous ciphertext block before being encrypted, and the message is padded—almost always with PKCS#7—to fill the final block. The guide's comparison table sums up the trade-off: CBC delivers confidentiality only, decrypts sequentially rather than in parallel, and carries a well-documented vulnerability profile involving padding oracles and bit-flipping.

The padding oracle attack

The first failure mode the dev.to article dissects is the padding oracle, the attack class behind POODLE and originally described by Vaudenay. When a server decrypts a CBC-mode message, it inspects the trailing bytes to check that the PKCS#7 padding is well formed. Invalid padding produces one error, such as an HTTP 400 or 500, while valid padding followed by garbage content produces an application-level error like an HTTP 401. That observable difference is the oracle. According to the guide, an attacker who intercepts an encrypted cookie or session token can modify individual bytes in a preceding ciphertext block, cycle through all 256 possible values, and use the server's differing responses to recover the plaintext one byte at a time—without ever obtaining the secret key.

Bit-flipping without the key

The second failure mode is simpler. Because CBC decryption XORs each ciphertext block with the block before it, flipping a bit in ciphertext block C(i-1) flips the corresponding bit in the decrypted plaintext block P(i). The neighbouring plaintext block turns into noise, but the targeted block changes predictably. The guide's worked example: if an attacker knows a block contains "role=user;", carefully chosen bit flips in the previous ciphertext block can rewrite the decrypted output to "role=root;". Confidentiality on its own does nothing against an attacker who would rather alter ciphertext than read it.

How AES-GCM does it differently

AES-GCM pairs Counter Mode encryption with GHASH, a polynomial hash over the Galois field GF(2^128), producing authenticated encryption with associated data (AEAD) in a single primitive. Encryption works like a stream cipher: a 96-bit IV or nonce is combined with a 32-bit counter to generate keystream blocks, which are XORed with the plaintext. No padding is added, and the final block is truncated to the exact message length. In parallel, a hash subkey is derived by encrypting a block of zeros, and GHASH is evaluated over the ciphertext plus any associated data—unencrypted headers or routing metadata—before the result is combined into a 128-bit authentication tag. The tag is the tamper check: the guide frames it as the mechanism that catches even a single altered bit in the ciphertext or associated data.

The catch: nonce reuse

GCM's guarantees collapse when the IV is reused. The article's comparison table is blunt about the consequence—IV reuse breaks both key confidentiality and authentication—which is why the guide treats nonce collisions as a critical pitfall rather than an implementation detail.

Why it matters

The dev.to guide points to TLS 1.3, NIST SP 800-38D, and the Web Cryptography Working Group as evidence that CBC has been systematically phased out, yet the mode still appears in legacy production systems and copy-pasted tutorials, often guarding session tokens, OPFS or IndexedDB storage, and REST API payloads in the browser. The practical takeaway for developers is that mode selection matters as much as key length, and the standard Web Crypto API makes the safer path a zero-dependency one: use AES-GCM with a unique nonce per message, authenticate associated data, and treat any unauthenticated ciphertext as untrusted input.