What is Data Encryption at Rest and In 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 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

The two protections — and what each actually stops

The honesty table the ranking pages omit — including the column that matters most:

             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 / 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 — Back4app Flutter SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
final user = ParseUser('ada', secret, '[email protected]');
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

// 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

// 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 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:

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

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

Limitations and trade-offs

• Encryption is not access control. The layered-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 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 applied to data. Then the piece encryption cannot do: ACLs and class-level permissions govern who reads what, because the control that stops a credentialed attacker was never cryptography — it was authorization.