Sure, encryption is not what keeps most of us going in the morning. Your main priority is to launch features, fix errors, and run your CI/CD smoothly. However, the sad reality is that in case your app deals with authentication, financial info or any other sensitive information encryption will be your best and last resort once other security mechanisms fail.

Unfortunately, data breaches are not some rare occurrences in large corporations anymore. They affect all types of companies from startups and small businesses to larger applications and services, and one thing which is consistent in many data breaches is an underestimation of encryption by people.

This doc will surely help you out to understand the basic principles of data encryption and it’s practical applications and pitfalls to avoid. If you are working on a new product or audit some existing one, this will be a useful resource for you for sure.

What Is Data Encryption?

Data encryption is about converting readable language into unreadable(ciphertext) format by using some encryption algorithm and an encryption key. Encryption keys are the unique sets of data that are specifically used for encrypting/decrypting data.If you don’t have the keys then the ciphertext is just meaningless data that you have.

Here’s the mental model I always come back to:

Plaintext  +  Encryption Key  →  Ciphertext   (encryption) 
Ciphertext +  Decryption Key  →  Plaintext    (decryption)

Two things determine how strong that guarantee is: the algorithm you choose and how well you manage the keys. I’ll say this upfront because it comes up in almost every section: mathematically sound encryption can be completely undone by poor key management. The algorithm is only part of the equation

Types of Encryption

The two foundational categories of encryption are symmetric and asymmetric, and understanding the difference is essential before choosing the right tool for a given use case.

Symmetric Encryption

Symmetric encryption uses the same key for both encryption and decryption. Therefore, symmetric encryption is fast and effective. It can be used to encrypt large volumes of data (files, database fields, storage volumes). 

The most commonly used symmetric algorithm today is AES-256 (Advanced Encryption Standard). ChaCha20 is quickly gaining in popularity for use in mobile and embedded systems primarily due to its speed.

The biggest risk is getting the encrypted ciphertext to the appropriate user once the shared secret key has been compromised (opening up all encrypted data protected under this shared key).

Asymmetric Encryption

The asymmetric cryptograph uses one public and one private key. A public key which can be openly shared and a private key held only by its owner. Using the asymmetric encryption, only the one with the private key can access data encrypted using that public key.

Asymmetric cryptography is mainly used for secure key exchange over an untrusted channel, digital signatures/verification or authentication of messages; and TLS (HTTPS), SSH, and PGP protocols all employ asymmetric cryptography. And the most common asymmetric cryptography algorithms are RSA encryption and elliptic curve cryptography (ECC) algorithms.

However, operations using asymmetric keys are substantially slower than operations utilizing symmetric keys. As such, most modern protocols use asymmetric encryption to securely transmit a symmetric session key, followed by the use of symmetric encryption when transmitting data.

Symmetric vs. Asymmetric — Quick Comparison

Feature	Symmetric	Asymmetric
Keys Used	One shared key	Public + Private key pair
Speed	Very fast	Slower (computationally intensive)
Best For	Bulk data, storage, databases	Key exchange, auth, digital signatures
Key Distribution	Challenging (must share securely)	Easy (public key is freely shareable)
Common Algorithms	AES-256, ChaCha20	RSA, ECC, Diffie-Hellman
Used In	Disk encryption, DB field encryption	TLS handshake, SSH, PGP, JWT signing

Encryption Strategies Every Developer Should Follow

Understanding encryption theory is one thing, knowing how to apply it in a real application is another. Below are five strategies that should be part of every developer’s security toolkit.

1. Always Enforce HTTPS

HTTPS is the bare-bones encryption layer for all the applications that operate over the internet. It encapsulates the HTTP traffic in TLS (Transport Layer Security), so that data transmitted from the client to your server cannot be read or manipulated while it is in transit.

Login credentials, session tokens and API response are transmitted in cleartext — anybody with access to the network can read those without HTTPS. Behaviour becomes trivial to spoof – Attacks like MITM interception, passive packet sniffing, etc.

Beyond just enabling HTTPS, developers commonly miss these other recommendations:

• Use modern TLS: The Modern TLS (Transport Layer Security) protects data in transit level by encrypting communication, preventing eavesdropping and tampering by attackers.
• Pick strong cipher suites: Use only reliable algorithms as cipher suites. Avoid any legacy algorithm, such as RC4 and DES, or anything marked “export-grade”, as these will no longer be viable for today’s security architecture.
• Turn on HSTS: HTTP Strict Transport Security stops attackers from forcing a downgrade to plain HTTP. It’s a must.
• Redirect HTTP to HTTPS at the server level: Don’t leave this to your app code alone. Let your web server handle the redirect. It’s cleaner and more reliable.
• Automate certificate renewal: Let’s Encrypt + Certbot is the standard for most setups. Set it and forget it before your cert expires at 2 AM on a Sunday.

2. Use Strong Password Hashing

It is essential to note that there is a difference between encryption & hashing of passwords. While encryption can be done with reversible algorithms, hashing uses one-way algorithms.

Whenever an application provides its users with the ability to store a password in the database, if the application has the ability to “decrypt” the stored password, it represents a significant flaw in the application’s design.

When it comes to hashing passwords, only two things really count. The first thing is that every password needs its own salt. That’s just a random string unique to each user, stirred in before hashing. Skip the salt, and attackers can use precomputed lookup tables to break thousands of passwords in one go. Second, the hashing process has to be intentionally slow. Not unusably slow, but slow enough that brute-forcing through millions of guesses becomes a real headache and an expensive one at that.

If you’re choosing a hashing algorithm right now, here’s what you should go with:

• Argon2id — This is the current gold standard. It won the Password Hashing Competition and is the right default for anything you’re building from scratch.
• Bcrypt — Been around long enough to be trusted everywhere. If your framework already uses it, you’re in good shape.
• Scrypt — Designed to be heavy on memory usage, which makes it much harder to crack using specialized hardware like GPUs or ASICs.

⚠️  Avoid These Algorithms for Password StorageMD5, SHA-1, and even plain SHA-256 are NOT suitable for password hashing. They are designed to be fast — which is exactly the wrong property here. Using them for password storage has been responsible for countless large-scale credential breaches.

Additional improvements that worth implementing:

• Require a minimum number of characters in password when accessing API.
• Implement Account Locking, after multiple attempts to enter a password and time-based rate limitation.
• Make use of constant-time comparison when querying for hashes preventing delays in processing.
• Consider using re-hashing on login if transitioning to stronger hashing.

3. Implement Proper Key Management

You can implement AES-256 encryption perfectly and still have a completely broken security posture if your keys are poorly managed. Key management is, arguably, the hardest part of applied cryptography — and the part most frequently handled carelessly in development environments.

The golden rules:

• Never hardcode keys in source code. A secret in source code is not a secret,  it will inevitably end up in version control, CI logs, or a Docker image layer.
• Never store keys in environment variables on their own. Env vars are accessible to any process and often get logged accidentally.
• Use a dedicated secrets management platform. AWS KMS, HashiCorp Vault, Azure Key Vault, and GCP Cloud KMS are the industry-standard options. They handle key storage, access control, audit logging, and rotation.
• Rotate keys regularly — and have a tested rotation procedure before you need it urgently.
• Separate keys by purpose and environment. Your dev, staging, and production environments should each have their own key sets.
• Restrict key access using least-privilege principles. Only the services that need a key should be able to access it.

💡  Key TakeawayThink of your encryption key as more valuable than the data it protects. A breach of the data is a problem. A breach of the key is a catastrophe  because it retroactively compromises everything encrypted with it.

4. Encrypt Data in Transit (Including Internal Traffic)

Any movement of information between multiple systems (from web browser to web server, from service to service, from application to database, from microservice to message queue) is data in motion. Securing external traffic through HTTPS is a common practice but many times, these types of attacks happen on internal traffic where there are often undiscovered gaps within the architecture.

In a microservices or cloud-based architecture, a single request from a customer generates multiple service-to-service requests. If these service-to-service calls travel unsecure between servers inside of the internal network, an attacker who has gained access to a section of a company’s internal network would have the ability to eavesdrop on everything that is transmitted.

Best practices for comprehensive transit encryption:

• Enforce mutual TLS (mTLS) for service-to-service communication in microservice architectures. Service meshes like Istio and Linkerd handle this automatically.
• Use secure WebSockets (WSS, not WS) for real-time communication channels.
• Encrypt connections to databases and caches. Most managed services (RDS, Redis, MongoDB Atlas) support TLS connections; enable them.
• Avoid passing sensitive data in URLs or query parameters. They can appear in server logs, browser history, and referrer headers.

5. Secure API Payloads

PIs are basically the nervous system of any modern app, always running, always sending data, and always out in the open. Every endpoint you put out there is an entry point, and the real question isn’t just whether it’s protected, but what’s actually accessible through it.

A lot of teams turn on HTTPS and figure they’re done but they’re not. Encrypting the connection keeps your data safe while it’s moving from one place to another. It helps to not expose anything about what’s packed inside that data, where it ends up getting stored, or whether someone managed to quietly change something before it arrived.

Here’s what you should actually be thinking about when it comes to keeping your API payloads secure:

• Send only what’s needed. Your API responses shouldn’t be generous. If the client needs a username, send a username, not the full account object. Full card numbers, SSNs, passwords? Those have no business appearing in a response, even in truncated form.
• Stop exposing your internals. Database primary keys and internal IDs in your API responses are a gift to anyone mapping out your system. Use opaque tokens or surrogate identifiers instead  they carry no meaningful information on their own.
• Treat incoming data like it’s hostile. Client-submitted input is not to be trusted, ever. Enforce your type checks, length limits, and format rules on the server side  not just in the frontend where anyone can bypass them.
• Handle JWTs with care. They’re convenient, but convenience breeds sloppiness. Sign your tokens with RS256 or ES256 rather than HS256, and make sure you’re actually verifying the signature, expiry, and audience on every single request  not just assuming they’re valid.
• Sign sensitive requests. For operations that really matter, HMAC-based request signing gives you a way to confirm that what the server receives is exactly what the client sent,  no silent modifications in between.

Common Mistakes Developers Make (And How to Avoid Them)

Even developers who’ve been doing this for years slip up with encryption and usually not because they don’t know better. You’re deep in a sprint, working on code someone else wrote three years ago, and you make a call that feels fine at the moment. That’s usually where things go wrong. The same problems come up again and again

• Leaving sensitive data in plaintext. Passwords, tokens, anything related to real person data which is stored as a plain text is so vulnerable. If you’re going back and forth on whether something needs encrypting, stop debating and just encrypt it.
• Reaching for outdated algorithms. MD5, SHA-1, DES, 3DES  the security community moved on from these a long time ago, but they keep turning up in live systems, usually tucked inside some library nobody’s looked at in years. Go check what your packages are actually using under the hood.
• Treating keys carelessly. A key sitting in a Git commit, baked into a Docker image, or left in an .env file isn’t a key anymore. It’s a liability. The moment a key gets exposed, even for a few minutes, treat it as compromised and rotate it immediately. No exceptions.
• Reusing nonces or IVs. This one is particularly nasty in AES-GCM. Reusing a nonce with the same key doesn’t just weaken encryption. It can shatter confidentiality entirely. Every single encryption operation gets its own freshly generated nonce. Every time.
• Encrypting without authenticating. Encryption only scrambles your data. It doesn’t make sure nobody messed with it. Skip the integrity check and an attacker can poke at the ciphertext until it decrypts into something completely different, and your app won’t notice a thing.
• Disabling certificate validation and forgetting to turn it back on. Setting ssl_verify=False to get past a local dev annoyance is something almost everyone has done. What’s dangerous is when it follows the code into staging or production. Make your test environments scream when certificate validation is off. It should never be silent.
• Neglecting encryption at rest. HTTPS handles the wire. It does nothing for data sitting in your database, your object storage, or your backup snapshots. Enable infrastructure-level encryption at rest as a baseline, and for anything genuinely sensitive, add application-level encryption on top of that and don’t rely on the infrastructure alone.

Conclusion: Encryption Is a Practice, Not a Checkbox

Throwing encryption at your app without really thinking it through is like locking your front door and leaving every window open. Sure, you've got HTTPS running, passwords are hashed, data is encrypted  but if your keys are a mess, your algorithms are outdated, or there's one small bug hiding somewhere, none of that actually protects you.

The developers who build genuinely secure systems don't set it up once and walk away. They revisit their encryption as things change, swap out keys before something goes wrong rather than after, and make sure that when something breaks, it breaks loudly, not in a way that quietly causes damage while nobody's watching.

All the tips in this post, like locking down HTTPS with fresh TLS, picking solid password hashers, nailing key management, protecting internal comms, and bulletproofing API data they're not some elite hacker tricks. They're just table stakes for any app touching real user info in production.

Bottom line: Don't bolt security on as an afterthought at sprint's end. Weave it into your architecture from commit one. And encryption? It's your secret weapon, just wield it right, and it'll save your bacon.

✅  Quick Recap — Encryption Checklist for Developers HTTPS with TLS 1.2+ enforced on all endpoints (external and internal) Passwords hashed with Argon2id or bcrypt — never encrypted, never MD5/SHA-1 Encryption keys stored in a secrets manager — never in code or env files Service-to-service communication encrypted (mTLS or equivalent) API payloads using authenticated encryption (AES-GCM) for sensitive fields Data at rest encrypted at infrastructure and/or application levelKey rotation procedures documented and tested