"Don't worry, everything's encrypted" comes up a lot when I ask founders about their data. It's usually said with real relief, like it settles the question completely. It settles part of it. It doesn't touch the part that actually causes most of the incidents I write about.
What encryption at rest actually protects against
Most managed databases and cloud storage encrypt your data at rest by default now, meaning the raw files sitting on a disk somewhere are scrambled and unreadable without the right key. That's genuinely useful protection against one specific scenario: someone physically stealing a hard drive, or gaining low-level access to storage infrastructure outside the normal application layer. For most small apps on managed hosting, that scenario is already unlikely and the encryption is often just handled for you.
What it has absolutely nothing to do with
Your application, when it runs normally, decrypts that data automatically to serve it through your API, the same way it would for a completely legitimate request. Encryption at rest doesn't ask 'should this specific logged-in user see this specific row.' It only asks 'is this file readable without the key,' and your running application already has the key by definition, because it needs it to function.
This means encryption at rest does absolutely nothing to stop the single most common problem on this blog: a missing or incorrect access rule that lets one logged-in user's request pull back another user's data. The database happily decrypts the row, because a legitimate, authenticated request asked for it. It has no way to know that request came from the wrong person, because that's not the question encryption was ever built to answer.
The two questions, kept separate
- Encryption at rest answers: if someone steals the raw storage, can they read anything without the key? For most managed platforms, yes, this is handled, and no.
- Access control answers: when a normal, authenticated request comes in, does the app correctly check whether this specific user is allowed to see this specific data? This is the one that's actually optional, easy to get wrong, and responsible for nearly every real incident.
Both matter. Only one of them is usually handled for you automatically by whatever platform you're building on. The other one is a set of rules you, or whoever built your backend, has to write and verify on purpose, table by table, and "it's encrypted" is not evidence that step happened.