Cybersecurity glossary

What are Cryptographic Failures?

Learn what cryptographic failures are in the OWASP Top 10 (formerly sensitive data exposure), how weak crypto and key handling leak data, and how to protect sensitive information in transit and at rest.

Application securityUpdated August 11, 2026
Also known asOWASP A02 Cryptographic FailuresSensitive Data ExposureWeak cryptography

Definition

Cryptographic Failures is an OWASP Top 10 category (A02:2021, formerly Sensitive Data Exposure) covering weaknesses in protecting data through cryptography—missing encryption, weak algorithms, poor key management, and incorrect use of crypto that leaves sensitive data recoverable by attackers.

Why cryptographic failures matter

Breach reports often cite “unencrypted” or “weakly protected” data. Cryptographic Failures (OWASP A02)—the successor framing to sensitive data exposure—covers missing encryption, weak algorithms, and broken key practices that make confidentiality fail even when the rest of the app looks solid.

Attackers do not need to break AES when keys sit in a repo, TLS is optional, or passwords are hashed with a fast general-purpose digest.

How cryptographic failures are abused

1

Identify valuable data

Credentials, PII, tokens, payment data, and secrets become targets for theft or interception.

2

Find weak protection

Cleartext channels, outdated ciphers, client-side-only 'encryption', or recoverable password stores.

3

Recover or intercept data

Network sniffing, stolen backups, repo secrets, or offline cracking yield plaintext.

4

Reuse impact

Account takeover, fraud, secondary breaches, and regulatory exposure follow.

Failure patterns under A02

Missing encryption

Sensitive fields or links travel or rest in cleartext without a compensating control.

Weak or wrong crypto

Obsolete ciphers, ECB misuse, or rolled-your-own schemes that look encrypted but are not safe.

Key mismanagement

Hard-coded keys, no rotation, shared secrets across tenants, weak RNG.

Password storage mistakes

Plaintext, reversible encryption, or fast hashes without salt and adequate work factors.

Protecting data with sound crypto

ControlNotes
Classify dataKnow what is sensitive and where it flows before choosing controls
TLS everywhereEnforce modern TLS; disable weak protocols and ciphers
Proven librariesUse vetted crypto APIs; never invent algorithms or protocols
Managed keysStore keys in KMS/HSM patterns; rotate and separate from ciphertext
Password KDFsHash passwords with Argon2/bcrypt/scrypt/PBKDF2 and unique salts
Minimize retentionDo not store secrets you can avoid; tokenize or truncate when possible
  • Map sensitive data stores, backups, logs, and message queues for cleartext exposure.
  • Enforce HTTPS and HSTS; reject plaintext credential submission.
  • Remove hard-coded keys and secrets from source and container images.
  • Upgrade password hashing to a modern KDF with appropriate cost parameters.
  • Review cipher suites and certificate validation in all clients and servers.
  • Ensure encryption keys are not readable by every process that can read ciphertext.
  • Redact secrets from logs, error pages, and support tooling.
  • Test restores and key rotation so crypto operations survive real operations.

The practical takeaway

Cryptographic Failures (OWASP A02) are about protecting data with correct, modern cryptography—not checkbox encryption. Classify sensitive data, use TLS and vetted libraries, manage keys properly, and hash passwords with purpose-built KDFs.

Related security terms

Frequently asked questions

What are cryptographic failures in simple terms?

Sensitive data is not protected properly: no TLS, outdated ciphers, hard-coded keys, reversible password storage, or encryption used incorrectly so attackers can still read the data.

How does A02 relate to sensitive data exposure?

OWASP renamed and refocused the category. A02 emphasizes failures of cryptography and crypto usage that lead to exposure, not only the symptom of data being visible.

Is using HTTPS enough?

HTTPS in transit is necessary but not sufficient. You still need sound at-rest protection, key management, password hashing, and careful handling of secrets in logs and backups.

What algorithms should be avoided?

Avoid MD5/SHA-1 for password hashing, DES/3DES, RC4, and homemade crypto. Prefer modern vetted libraries, TLS 1.2+, and purpose-built password KDFs (Argon2, bcrypt, scrypt, PBKDF2).

Where do keys commonly go wrong?

Keys in source code, shared across environments, never rotated, stored next to ciphertext, or generated with weak randomness.

Do encrypted databases fix A02?

Transparent disk encryption helps against stolen drives but not against SQL access by a compromised app. Application-level protection and least privilege still matter.

How should teams inventory crypto risk?

Classify data, map where it is stored and transmitted, list algorithms and key stores in use, and fix gaps with standards-based controls and tests.

References

Explore authoritative guidance and frameworks related to cryptographic failures.

Explore every security definition

Return to the glossary to search by term, alias, starting letter, or security category.

Browse glossary