01 The Problem

A mobile app makes an API call carrying a session token in a header, over plain HTTP, maybe a service-to-service call someone assumed was safe because it's inside a private network, or a public endpoint nobody forced onto HTTPS. Anyone positioned on that network path, coffee-shop WiFi, a compromised router, another tenant on the same internal network segment, can read the request in plaintext and lift the token straight out of it. No password to guess, no bug to exploit, no authentication to bypass. The token was sitting there in the clear, and replaying it in their own request makes the server treat them as the original user without a second thought.

The team fixes this, forces HTTPS everywhere, and calls it done. Six months later the database gets breached, backups included, and every session token, every weakly hashed password, every field in every row is sitting there for whoever has the dump, because HTTPS was never protecting any of that. It protected the connection those records traveled over on their way into the database. It never touched what happens to them once they're sitting on disk.

This is the actual distinction. TLS encrypts data in transit. It says nothing about data at rest. Treating "we use HTTPS" as a general answer to "is our data encrypted" answers a question about one leg of the data's life with an answer that only ever covered that leg.

02 What It Is

TLS, Transport Layer Security, encrypts the connection between two endpoints, a client and a server, so anything traveling over that connection is unreadable to anyone intercepting it in the middle. It protects data in transit, while it's moving from one place to another, through a handshake that establishes a shared key and then encrypts everything sent over that connection using it, for the life of that connection.

Encryption at rest is a separate concern entirely: whether data sitting on a disk, in a database, in a backup, in a log file, is itself encrypted, independent of how it got there. A database can sit behind a perfectly configured TLS connection and still store every column in plaintext, meaning anyone who gets direct access to the disk, a stolen backup, a misconfigured storage bucket, an insider with database access, reads everything without needing to intercept any network traffic at all.

TLS is close to a solved problem now, certificates are free, most frameworks force HTTPS by default, and getting it wrong usually means an obvious, visible browser warning that gets fixed quickly. Encryption at rest is quiet by comparison: a database with no column-level encryption looks and behaves completely normally, every query works, every feature ships, right up until a breach or a leaked backup shows exactly how much was never protected there in the first place. The gap isn't technical difficulty, both are mature, well-supported technology. It's that "we're using HTTPS" feels like it already answered the question, and stops the conversation before anyone asks what happens to the data once it lands.

In Plain Terms

An armored truck can drive cash from a store to a bank in perfect safety, nobody on the road can touch it, and that says absolutely nothing about whether the vault it arrives at has a working lock. The truck protects the trip. The vault protects the destination. A robbery at the vault isn't a failure of the truck, they were never the same job.

03 How It Works

Rendering diagram…

Rendering diagram…

04 Trade-offs

	Encryption in transit (TLS)	Encryption at rest
What it protects	Data while it's moving between two points, a request, a response	Data while it's sitting still, in a database, a file, a backup
What defeats it	Nothing, if configured correctly; an interceptor on the network path gets ciphertext	Direct access to the storage layer, a stolen disk, a leaked backup, a database dump
How obvious a failure is	Very: a browser warning, a failed handshake, immediately visible	Not obvious at all: an unencrypted database behaves identically to an encrypted one until it's breached
Default state today	Usually on by default in modern frameworks and hosting	Usually opt-in; has to be deliberately configured per field, table, or volume

05 Where You'll Actually See This

Neither case study discusses transport or storage encryption explicitly, and the payment gateway case study is exactly where that silence matters most: a charge ledger and an idempotency-key store are precisely the kind of financially sensitive data that needs both legs covered, TLS on every hop, and encryption at rest on the ledger and cache, neither of which the case study's diagram shows and both of which a real version would need.

JWT & Sessions and OAuth and OpenID Connect both spend real effort on revocation, how fast access can be taken back once it needs to be. Neither revocation story means anything if the token was readable in transit in the first place. A stolen token intercepted over plain HTTP is just as usable to an attacker as a forged one, and it doesn't matter how quickly a compromised token can theoretically be revoked if nobody knows it was ever stolen. TLS is the assumption both of those articles are quietly standing on.

Password hashing is worth separating from encryption at rest, even though both turn readable data into something unreadable and get lumped together as "we protect our data." Encrypted data is meant to come back, decrypted by whoever holds the key, which is exactly right for a credit card number a system needs to charge again later. A password hash is never meant to come back at all, not even for the server that stored it. Encrypting a password column instead of hashing it defeats the purpose, anyone with the key can recover every password directly.

How to reason about it

When asked whether a system's data is encrypted, don't answer with "yes, we use HTTPS." Say which leg of the data's life you mean, in transit or at rest, because they're different controls protecting against different attackers, one on the network path, one with access to storage. An answer that only covers transit is a real answer to half the question, and a breach disclosure is usually where the other half gets found out.

06 Quick Check