Encryption at Rest vs in Transit, Explained

Security pages love the phrase "your data is encrypted in transit and at rest". It sounds comprehensive. It's a good start — but each half protects against specific threats, and neither protects against the most common way data actually leaks. Here's what the terms mean.

Data has three states

In transit: moving across a network — from a browser to your server, from your server to your database, from your app to an API.
At rest: stored — on a disk, in a database, in a backup, in file storage.
In use: being processed in memory by your running app.

Encryption scrambles data so only someone with the right key can read it. Different techniques protect different states.

Encryption in transit

What it protects: data while it travels, from anyone who can see the network traffic — someone on the same café Wi-Fi, a compromised router, an internet provider.

How: TLS — the technology behind HTTPS. (What is HTTPS?) It applies to more than websites:

browser ↔ your app: HTTPS,
your app ↔ database: TLS on the database connection (sslmode=require or verify-full for Postgres — see Postgres connection strings),
your app ↔ third-party APIs: HTTPS,
you ↔ your server: SSH. (SSH keys explained.)

What it doesn't protect: data once it arrives. The server decrypts it to use it.

Encryption at rest

What it protects: stored data from someone who gets the physical storage or a copy of it — a stolen laptop, a discarded hard drive, a leaked backup file, a misconfigured storage bucket exposing raw files.

How:

Full-disk encryption — the whole disk is encrypted; the operating system decrypts it transparently. Most cloud providers encrypt their storage like this by default.
Database or storage encryption — managed databases and object storage typically encrypt their files.
Encrypted backups — backups encrypted with a key stored separately.

What it doesn't protect: data accessed through the running system. When your app reads from the database, the data is decrypted automatically. If an attacker logs in to your app as another user, or exploits a bug in your API, at-rest encryption does nothing — the system happily decrypts the data for them.

The gap both leave open

Most real-world data leaks in small apps don't involve stolen disks or intercepted traffic. They involve the application itself handing data to the wrong person:

an API that returns other users' records (IDOR explained),
a database table readable by anyone (Supabase RLS),
a leaked API key or database password (leaked API key),
SQL injection. (SQL injection explained.)

"Encrypted in transit and at rest" is necessary, but access control is what protects data in practice.

Field-level (application-level) encryption

For especially sensitive fields — say, a user's government ID number, or a third-party API token your app stores on their behalf — you can encrypt the value in your application code before saving it. The database then only ever sees ciphertext. Even someone with full database access (or a database backup) can't read it without the key, which is kept separately.

Use a well-known library and an authenticated encryption algorithm (like AES-GCM), store the key in a secrets manager or environment variable — not in the database — and plan for key rotation. Don't invent your own scheme. (Secrets management beyond .env files.)

Passwords are different: never encrypt them — hash them, so they can't be decrypted at all. (Password hashing explained.)

What a small app actually needs

HTTPS everywhere — usually automatic with modern hosts. (How automatic SSL works.)
TLS to your database if it's reached over a network.
A host whose storage and backups are encrypted — ask, or check their security page.
Hashed passwords.
Field-level encryption only for the few truly sensitive values.
Strong access control in your app — the part encryption can't do for you.

The summary

In transit = protected while moving (TLS/HTTPS/SSH). At rest = protected while stored (disk, database, backup encryption).
Neither protects data accessed through your running app.
Field-level encryption adds protection for a few sensitive values; passwords are hashed, not encrypted.
Access control prevents the leaks that actually happen most.

EasySpawn serves every app over HTTPS, runs each server as its own isolated virtual machine, and keeps your secrets as server-side environment variables — the foundations, so your attention can go on access control in your app. See how it works or join the waitlist.

Encryption at Rest vs in Transit: What's the Difference?