Encryption basics for engineers — at rest, in transit, and what 'encrypted' doesn't mean
"We encrypt everything" is a genuinely common, real claim that hides a lot of important detail — encryption at rest and encryption in transit protect against completely different threats, and neither one protects against the application itself misusing data it's legitimately allowed to decrypt.
4 min read
Encryption in transit: protecting data while it moves across a network
HTTP (unencrypted): a request between a browser and a server travels
as PLAIN TEXT across every network hop in between — any router, ISP,
or attacker on a shared WiFi network can read it directly
HTTPS (TLS): the SAME request is encrypted before leaving the browser,
decrypted only once it reaches the server — anyone intercepting the
traffic in between sees only unreadable, encrypted bytes
Encryption in transit (TLS, what makes HTTP become HTTPS) protects data specifically while it's moving across a network, between two endpoints — a browser and a server, or two servers communicating. This is what HSTS (from this domain's security-headers lesson) enforces the use of, and it protects against a real, specific threat: someone positioned on the network path between the two endpoints reading or tampering with data in transit.
Encryption at rest: protecting data while it's stored, not while it moves
A database file sitting on a disk, UNENCRYPTED: if someone gains
access to the raw disk (a stolen physical drive, a misconfigured
cloud storage bucket, a backup file leaked somewhere) they can read
the data DIRECTLY, with no network interception needed at all
The SAME database, encrypted AT REST: the raw disk contents are
unreadable without the encryption key, even with direct access to
the storage medium itself
Encryption at rest protects data while it's sitting in storage — a database, a file, a backup — against someone who gains access to the storage medium itself, entirely independent of network transit. This is a genuinely different threat than encryption in transit protects against: TLS does nothing to protect a database backup file that gets accidentally uploaded to a public cloud storage bucket, since the data was never in transit in that scenario at all — it was already at rest, unencrypted, and directly exposed.
Symmetric vs. asymmetric encryption: one key vs. a genuine pair
SYMMETRIC (AES, for example): the SAME key both encrypts and decrypts —
fast, efficient, but the key itself has to be shared between both
parties SOMEHOW, safely, before it can be used at all
ASYMMETRIC (RSA, for example): a PAIR of mathematically related keys —
a public key that ENCRYPTS (safe to share with anyone) and a private
key that DECRYPTS (kept secret) — solves the "how do we share a key
safely" problem, but is genuinely slower than symmetric encryption
Symmetric encryption uses one shared key for both directions, which is fast but requires the two parties to already have a safe way to exchange that key. Asymmetric encryption uses a genuine key pair — data encrypted with the public key can only be decrypted with the corresponding private key — which solves the key-distribution problem (the public key really can be shared openly) at the cost of real computational overhead. In practice, TLS actually uses both together: an initial asymmetric handshake to safely establish a shared secret, then fast symmetric encryption for the actual data using that now-shared secret — combining each approach's strength where it matters.
What "encrypted" does NOT protect against: the application's own legitimate access
A database column encrypted at rest is UNREADABLE to someone who steals
the raw disk — but the APPLICATION itself, which holds the decryption
key to do its normal job, can read it perfectly fine, every time it
runs a normal query. If an ATTACKER compromises the running application
itself (not just the storage), encryption at rest provides NO protection
at all, since the app decrypts the data as part of its ordinary operation
Encryption at rest specifically protects against someone accessing the raw storage medium directly, bypassing the application entirely — it does nothing to protect against an attacker who has compromised the application itself, since the running application legitimately holds the key and decrypts data as part of normal operation, and an attacker with that same access sees exactly what the application sees. This is a genuinely common, real point of confusion: "the data is encrypted" is not a blanket security guarantee — it specifically closes the "someone got the raw disk/backup" threat, and every other lesson in this domain (SQL injection, broken access control, XSS) remains just as relevant regardless of whether the underlying data happens to be encrypted at rest.
Further reading
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. What's the actual difference between what encryption in transit and encryption at rest each protect against?
2. Why does TLS use both asymmetric AND symmetric encryption together, rather than just one?
3. Why doesn't 'the data is encrypted at rest' protect against an attacker who has compromised the running application itself?