Would you ever send your credit card info on a postcard? That’s exactly what it’s like when encryption is missing or broken in an application.
The second item in the OWASP Top 10 is Cryptographic Failures — previously known as Sensitive Data Exposure. The name changed, but the issue remains: sensitive information isn’t properly protected.
What does a cryptographic failure look like in the real world?
Here are some examples:
- A login form sends your password over plain HTTP, making it easy for someone on public Wi-Fi to steal it.
- A company stores credit card numbers in their database without encryption — if the database is breached, everything is exposed.
- An app uses outdated algorithms like MD5 or SHA-1, which can be cracked in minutes with today’s computing power.
- Developers hardcode encryption keys in the source code — and the code gets leaked on GitHub.
- A mobile app encrypts data but doesn’t validate certificates, leaving it vulnerable to man-in-the-middle attacks.
Encryption isn’t just a technical detail — it’s what protects our identities, financial data, and private messages from being exposed.
What should teams do instead?
- Use HTTPS everywhere — no exceptions.
- Encrypt sensitive data at rest and in transit.
- Use modern, well-reviewed libraries (e.g., AES-256, TLS 1.3) — never write your own crypto.
- Store and manage keys securely (use a key vault, rotate regularly).
- Always validate certificates and use secure protocols.
🛡️ Good encryption is invisible when done right — and disastrous when done wrong.
Before shipping a product, ask:
“If someone intercepted this data, would encryption protect it — or just look like it does?”
If you’re unsure, now’s the time to double-check.