---
term: 'Data Encryption at Rest and In Transit'
seoTitle: 'Encryption at Rest vs. In Transit: TLS, AES-256, Key Management'
headline: 'What is Data Encryption at Rest and In Transit?'
slug: data-encryption-at-rest-transit
category: auth-security
shortDefinition: 'Encryption at rest is a control that makes stored data unreadable without keys; encryption in transit protects data crossing networks.'
relatedTerms:
- data-layer-vs-application-layer-security
- row-level-security
- api-key-security
- tenant-isolation
contrastsWith:
- data-layer-vs-application-layer-security
aboutTerms:
- 'Encryption at Rest'
- 'Encryption in Transit'
- 'TLS'
- 'Key Management'
faq:
- question: 'What is encryption at rest?'
answer: 'Encrypting stored data — disks, databases, backups, object storage — so that whoever obtains the storage medium without the keys holds ciphertext. The standard is AES-256; the protection is against stolen hardware, leaked backups, and breached storage layers.'
- question: 'What is encryption in transit?'
answer: 'Encrypting data while it crosses networks so intercepted traffic is unreadable — the job of TLS, which is what the S in HTTPS delivers. It protects against eavesdropping and man-in-the-middle attacks on any hop between client and server.'
- question: 'What is the difference between encryption at rest and in transit?'
answer: 'Different data states, different threats. At-rest defends stored copies against theft of media and backups; in-transit defends moving data against wiretapping. They are complements, not alternatives — every serious security framework expects both, because each stops attacks the other cannot see.'
- question: 'Is HTTPS the same as TLS?'
answer: 'HTTPS is HTTP carried over TLS, the cryptographic protocol securing the connection. TLS 1.3 is current — faster handshakes, weak ciphers removed, forward secrecy mandatory; versions 1.0 and 1.1 are formally deprecated and should be disabled.'
- question: 'What is AES-256?'
answer: 'The Advanced Encryption Standard with a 256-bit key — a symmetric block cipher standardized by NIST, effectively immune to brute force, and the de facto choice for data at rest. In practice you want an authenticated mode like AES-GCM, which detects tampering as well as hiding content.'
- question: 'What is the difference between symmetric and asymmetric encryption?'
answer: 'Symmetric uses one shared key for both directions — fast, right for bulk data (AES). Asymmetric uses a public/private key pair — slower, right for key exchange, certificates, and signatures. TLS uses both: an asymmetric handshake agrees on a symmetric session key that encrypts the actual traffic.'
- question: 'How is end-to-end encryption different from encryption in transit?'
answer: 'Scope of trust. TLS protects each hop, but the server decrypts and can read everything. End-to-end encryption means only the communicating users hold keys — the service operator itself cannot read content. E2EE protects against the server; TLS protects the path to it.'
- question: 'Does encryption at rest protect against hackers?'
answer: 'Only against a specific kind: those who obtain the storage — stolen drives, leaked backups, misconfigured buckets. An attacker who compromises the application or steals credentials reads data freely, because the app decrypts legitimately. Encryption is not access control; it complements ACLs, never replaces them.'
- question: 'What is the difference between hashing and encryption?'
answer: 'Encryption is reversible with a key; hashing is deliberately one-way. Passwords must be hashed — with slow, salted algorithms like bcrypt or argon2 — never encrypted, because no one, including the server, should ever be able to recover them.'
- question: 'What is encryption key management?'
answer: 'The discipline that decides whether the cryptography means anything: generating keys properly, storing them separately from the data (envelope encryption — data keys wrapped by key-encryption keys in a managed service or HSM), rotating them, and revoking them. A key in a config file next to the database is theater, not protection.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
- name: 'NIST FIPS 197 — Advanced Encryption Standard (AES)'
url: 'https://csrc.nist.gov/pubs/fips/197/final'
- name: 'RFC 8446 — TLS 1.3'
url: 'https://datatracker.ietf.org/doc/html/rfc8446'
- name: 'NIST SP 800-57 — Key Management Recommendations'
url: 'https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final'
- name: 'OWASP Cryptographic Storage Cheat Sheet'
url: 'https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html'
- name: 'Encryption — Wikipedia'
url: 'https://en.wikipedia.org/wiki/Encryption'
cta:
title: 'Encrypted by default, end to end of your stack'
text: 'Back4app serves every API, file, and Live Query over TLS and stores data and backups encrypted — your remaining job is policy: hash-only passwords (built in), field-level encryption for the truly sensitive, and ACLs for access.'
linkText: 'Start building free'
linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-07-30'
translationKey: data-encryption-at-rest-transit
---
**Encryption at rest is a control that makes stored data unreadable without keys; encryption in transit protects data crossing networks.** Data lives in three states — at rest on storage, in transit on the wire, and in use in memory — and the first two are every application's baseline obligation: [AES-256](https://csrc.nist.gov/pubs/fips/197/final) for what sits, TLS for what moves. The third state (protected by trusted execution environments and, at the frontier, homomorphic encryption) is real but, for most application teams, someone else's layer.
## Key takeaways
| Question | Answer |
| --- | --- |
| At rest | AES-256 on disks, databases, backups — against stolen media |
| In transit | TLS 1.2+ on every connection — against wiretaps and MITM |
| The blind spot | Neither stops a compromised app — encryption is not access control |
| The real problem | Key management — keys stored next to data are theater |
| The confusion to retire | Passwords are *hashed* (bcrypt/argon2), never encrypted |
## The two protections — and what each actually stops
The honesty table the ranking pages omit — including the column that matters most:
```text
Standard Covers Stops Does NOT stop
In transit TLS 1.2+/HTTPS every network hop wiretaps, MITM, compromised endpoints —
coffee-shop snooping the server reads it fine
At rest AES-256 (GCM) disks, DBs, backups stolen drives, leaked stolen credentials,
backups, open buckets SQL injection, app bugs
In use TEEs RAM during processing memory scraping — mostly a platform concern
Neither stops an attacker the app itself trusts. The app holds keys and
decrypts on demand — encryption complements access control, never replaces it.
```
What the defaults look like from application code:
**JavaScript:**
```javascript
// JavaScript / Node.js — Back4app JS SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
const user = new Parse.User();
await user.signUp({ username: 'ada', password: secret });
// On the wire: TLS 1.2+ (the https serverURL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself
// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code
```
**Flutter:**
```dart
// Flutter / Dart — Back4app Flutter SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
final user = ParseUser('ada', secret, 'ada@example.com');
await user.signUp();
// On the wire: TLS 1.2+ (the https server URL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself
// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code
```
**Swift:**
```swift
// iOS / Swift — Back4app Swift SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
var user = User()
user.username = "ada"
user.password = secret
let signedUp = try await user.signup()
// On the wire: TLS 1.2+ (the https server URL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself
// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code
```
**Kotlin:**
```kotlin
// Android / Kotlin — Back4app Android SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
val user = ParseUser()
user.username = "ada"
user.setPassword(secret)
user.signUp()
// On the wire: TLS 1.2+ (the https server URL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself
// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code
```
## How TLS works, in one paragraph
The elegant trick: asymmetric cryptography is slow but needs no shared secret; symmetric is fast but needs one. So the [TLS handshake](https://datatracker.ietf.org/doc/html/rfc8446) uses the first to establish the second — the client verifies the server's certificate (the identity check that makes interception detectable), both sides agree on a fresh session key via asymmetric key exchange, and everything after rides fast symmetric encryption. TLS 1.3 tightened all of it: one round trip instead of two, legacy ciphers and RSA key exchange removed, forward secrecy mandatory — so recorded traffic can't be decrypted later even if the server's long-term key leaks. Mobile addendum the SERP skips: apps can additionally *pin* expected certificates, trading resilience against rogue certificate authorities for operational care at rotation time.
## The at-rest layers: disk vs. database vs. field vs. application
"Encrypted at rest" spans four very different promises — each defeating a different attacker:
| Layer | How | Defeats | Doesn't touch |
| --- | --- | --- | --- |
| Full-disk (LUKS/dm-crypt) | OS encrypts the volume | Stolen/discarded hardware | Anyone on the running system |
| Transparent (TDE) | Database encrypts files as written | Stolen data files and backups | Anyone with database credentials |
| Field/column-level | Specific columns encrypted, app holds keys | Curious DBAs, broader DB breaches | Compromise of the app itself |
| Application-level | Encrypted *before* reaching storage | Everything below the app | The app and its key store |
```mermaid
flowchart LR
accTitle: Envelope encryption keeping keys separate from data
accDescr: Application data is encrypted with a data encryption key. The data key is itself encrypted by a key-encryption key held in a key management service or hardware security module, so a stolen database contains ciphertext and wrapped keys but nothing that decrypts without the separately guarded key service.
D["Data"] -->|"AES-256-GCM"| C["Ciphertext
in database"]
DEK["Data key (DEK)"] -->|"encrypts"| D
KEK["Key-encryption key (KEK)"] -->|"wraps"| DEK
KMS["Key service / HSM
separate system, audited"] -->|"holds"| KEK
T["Thief with the database"] -.->|"gets ciphertext +
wrapped keys — nothing opens"| C
```
The rule down the whole table: **higher layers protect against more, cost more**. Field-level encryption is the honest trade — encrypted columns can't be indexed or searched normally (deterministic encryption restores equality lookups at some leakage cost) — which is why it's reserved for the genuinely sensitive: health data, government IDs, secrets. And the classic audit failure lives here: the encrypted database whose *backups* ship unencrypted.
## End-to-end encryption is a different promise
TLS everywhere still means the server reads everything — it decrypts each connection by design. End-to-end encryption moves the keys to the users: only sender and recipient can decrypt, and the operator serves ciphertext it cannot open. That's a different product decision, not a stronger setting: E2EE means no server-side search, no content moderation, no recovery if users lose keys. The threat models nest cleanly — TLS defends the path, at-rest defends the storage, E2EE defends against the service itself — and most applications correctly stop at the first two while messaging and vault products justify the third.
## Hashing vs. encryption
| | Encryption | Hashing |
| --- | --- | --- |
| Reversible | Yes — with the key | No — by design |
| Right for | Data you must read back | Passwords, integrity checks |
| Standards | AES-256-GCM | bcrypt, scrypt, argon2 (slow + salted) |
| The failure | Losing or leaking keys | Fast unsalted hashes (MD5, plain SHA-256) |
One callout retires a widespread confusion: **passwords are hashed, never encrypted.** Nobody — including the server — should be able to recover a password; login compares hashes. Encrypting passwords means a key exists that decrypts them all, which is exactly the catastrophe hashing exists to preclude.
## Common use cases
- **Every web and mobile app** — TLS on all connections and encrypted storage are table stakes, not features.
- **Regulated data** — GDPR names encryption an appropriate technical measure (with breach-notification relief), health rules mandate it for patient data, and payment standards require unreadable card numbers at rest and strong crypto in transit.
- **Backups and decommissioning** — encrypted backups and crypto-shredding (destroy the key, the data dies everywhere) close the stolen-copy chapter.
- **PII field protection** — application-level encryption for the columns whose leak is a headline, not an incident.
- **Mobile clients on hostile networks** — TLS plus certificate validation as the defense that travels with the user.
## Which layer do you need? A decision matrix
| Situation | Reach for |
| --- | --- |
| Any data, any app | TLS everywhere + platform at-rest encryption — the floor |
| Stolen-backup nightmare | Encrypted backups + keys stored elsewhere |
| Sensitive columns (health, IDs) | Field/application-level encryption, keys in env or KMS |
| "Even we shouldn't read it" | End-to-end encryption — accept the product costs |
| Passwords | Hashing (bcrypt/argon2) — never encryption |
| Access concerns, not theft concerns | [ACLs and row-level security](/glossary/row-level-security/) — encryption won't help |
## Limitations and trade-offs
- **Encryption is not access control.** The [layered-security](/glossary/data-layer-vs-application-layer-security/) point in one line: at-rest encryption is transparent to the running app, so permissions — ACLs, CLPs, row policies — remain the defense against every credentialed attacker.
- **Key management is the real project.** [NIST's guidance](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final) exists because generation, separation, rotation, and revocation — not algorithm choice — are where deployments fail.
- **Field-level encryption fights the database.** No indexes, no LIKE queries, careful migrations; encrypt the fields that need it, not the schema.
- **TLS ends at the terminator.** Proxies and load balancers that decrypt mid-path recreate plaintext hops; internal traffic needs the same discipline as the edge.
- **Compliance ≠ security.** Checkbox encryption with keys beside the data satisfies auditors and no one else; the threat-model column is the one to design against.
## Encryption on Back4app
Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. The floor is platform-provided: every REST, GraphQL, and Live Query connection rides TLS, and data and backups are encrypted at rest — the two baseline layers arrive as defaults rather than projects. The developer's remaining share is exactly what the code tabs sketch: passwords are bcrypt-hashed by Back4app out of the box (never stored, never recoverable — the hashing rule enforced structurally); truly sensitive fields get application-level encryption in a Cloud Code `beforeSave`, with the key in server-side configuration rather than code, so plaintext never reaches storage; and secrets stay out of logs, URLs, and client bundles — the [API-key discipline](/glossary/api-key-security/) applied to data. Then the piece encryption cannot do: [ACLs and class-level permissions](/glossary/access-control-lists-acl/) govern who reads what, because the control that stops a credentialed attacker was never cryptography — it was authorization.