Does HTTPS protect data stored in the database (data at rest)?

"We're encrypted — we use HTTPS" is one of the most common security half-truths. HTTPS is essential, but it solves exactly one problem, and stored data isn't it.

What HTTPS/TLS actually protects

TLS establishes an encrypted channel between two endpoints — typically a browser and a web server. It provides confidentiality and integrity for data in transit, plus server authentication via certificates. While bytes travel across the network, an attacker on the wire (public Wi-Fi, a malicious proxy, an ISP) sees only ciphertext. That is the entire job: protecting the conversation between client and server.

Where the protection ends

TLS is terminated at the server (or a load balancer / reverse proxy in front of it). At that boundary the session key decrypts the request back into plaintext, and the application processes it in the clear: parsing JSON, running business logic, building SQL. When the app writes to the database, what lands on disk depends entirely on how that storage is configured — by default, plaintext. The TLS session key never reaches the disk; it was ephemeral and is gone once the connection closes.

Data at rest is a separate control

Protecting stored data requires its own mechanisms:

• Full-disk or volume encryption (e.g. LUKS, BitLocker) against stolen drives.
• Transparent Data Encryption (TDE) or column/field-level encryption in the database.
• A Key Management Service (KMS) or HSM so keys aren't sitting next to the data.
• Access control and least privilege so only the right principals can read rows.

These defend against different threats than TLS: a stolen backup, a compromised DBA account, an attacker who already has a shell on the box.

Why the misconception is dangerous

The seductive wrong answers imagine the TLS key somehow "follows" the data onto disk, or that the certificate keeps protecting it at rest. It doesn't — TLS is point-to-point and ephemeral. Teams that conflate transport security with storage security skip at-rest encryption entirely and then leak plaintext databases. The right mental model: HTTPS protects the journey; at-rest encryption protects the destination. You need both.