Skip to content

CWE-345: Insufficient Verification of Data Authenticity

Overview

Insufficient verification of data authenticity occurs when an application accepts data without checking that it was not tampered with in storage or in transit: it takes unsigned data, skips the signature or MAC check, or trusts a source it never authenticated. An attacker can then tamper with the data, forge messages, or intercept and modify traffic in a man-in-the-middle attack.

Relationship to Other CWEs

Treat a finding filed as CWE-345 as a starting point rather than a destination. MITRE marks it DISCOURAGED for mapping because it "might have lower-level children that would be more appropriate", and tells you to "examine children of this entry to see if there is a better fit": work out which check is missing - a signature, a digest or MAC, the origin of a request, the integrity of code about to be executed - and report it against the child that names that check. Use this page when no child fits, or when the fix is the general one of putting an authenticated channel around data that currently travels without one.

Those children differ by what the missing check was meant to cover:

MITRE gives CWE-345 further children with no page here. Two of them are worth knowing by name because a finding that lands on this page is often one of them: CWE-353 (Missing Support for Integrity Check), where the protocol or format provides nowhere to carry a MAC at all, and CWE-924 (Improper Enforcement of Message Integrity During Transmission), where one exists but is not enforced on the wire. The remediation below covers both.

OWASP Classification

A08:2025 - Software or Data Integrity Failures

Risk

High: Missing authenticity checks enable message tampering, forged API requests, modified cookies and tokens, corrupted file uploads, MITM attacks, and replay attacks. Encryption alone does not prevent tampering.

Remediation Steps

Core Principle: Never allow untrusted data to influence security or control decisions unless its authenticity is verified by a server-controlled integrity mechanism (such as a signature or MAC) before use.

Locate the missing data authenticity verification

  • Find the code that accepts the data without an authenticity check
  • Identify what data lacks authentication: cookies, tokens, API messages, file uploads, database records, configuration data
  • Determine where the data comes from: the client, an external API, file storage, a database
  • Trace the data from where it is accepted to where it is used

Use message authentication codes (Primary Defense)

  • HMAC-SHA256: Generate HMAC-SHA256(secret_key, message) and send it with the message; verify the HMAC before trusting the data
  • Verify the MAC before using the data: Nothing in the message is trustworthy until the MAC or authentication tag checks out; reject a message that fails the check rather than processing part of it
  • Bind freshness into the authenticated bytes: A valid MAC or signature never expires, so a captured genuine message replays successfully forever - the replay attack named under Risk. Include a nonce, monotonic sequence number, or timestamp inside the region the tag covers, and reject anything already seen or outside the freshness window. A timestamp carried alongside the tag is attacker-controlled and worthless
  • Encrypted data: When the data must also be kept confidential, use authenticated encryption (next section), which provides confidentiality and integrity in a single operation

Implement digital signatures for critical data

  • RSA (RSA-3072 for new keys): Prefer RSA-PSS over PKCS#1 v1.5 for new designs. RSA-2048 is 112-bit strength and NIST-accepted for applying protection only through 2030, so size new keys at 3072 bits, the same figure CWE-347 gives
  • ECDSA (256+ bits): Use P-256 or P-384. Far smaller keys and signatures than RSA and much faster signing, but slower to verify than RSA, whose public exponent makes verification cheap. Measured with openssl speed rsa2048 ecdsap256 on a current desktop, ECDSA P-256 signs roughly 20-30x faster than RSA-2048 and verifies roughly 3-4x slower. Run it on your own hardware before trading one for the other on performance grounds
  • Ed25519: A modern signature scheme that is both fast and secure
  • Verify signatures on critical data: Software updates, configuration files, API responses, and contracts, in each case before acting on the content

Use authenticated encryption

  • AES-GCM: Encrypts and authenticates in a single operation, so tampering with the ciphertext is detected
  • ChaCha20-Poly1305: Modern authenticated encryption; faster on mobile and other systems without AES hardware acceleration
  • Not AES-CBC alone: CBC provides confidentiality only, so an attacker can modify the ciphertext without detection
  • Invalid authentication tag: Reject the entire message

Validate data integrity checks

  • Check the HMAC on received messages: compute the expected HMAC and compare it with the provided value using a constant-time comparison
  • Verify digital signatures on downloads: check the signature on software updates, documents, and files before installing or using them
  • Validate JWT signatures: verify with the key type the algorithm requires. The HMAC algorithms HS256, HS384 and HS512 take a shared secret; the asymmetric ones, RS, PS, ES* and EdDSA, take the issuer's public key. Pin the accepted algorithm from your own configuration rather than reading it from the token header, and reject alg=none. Letting the header choose is what turns a published RSA public key into an accepted HMAC secret - see CWE-347
  • Use TLS for transport (defense in depth, not a substitute): TLS decides who you are talking to; it says nothing about what they sent, and nothing at all once the data is stored. A compromised peer, a hijacked mirror, or an intermediary that terminates TLS all deliver over a valid certificate. Keep the MAC or signature check even on an HTTPS path

Test the authenticity verification fix

  • Send a message with no HMAC or signature: it must be rejected
  • Send authenticated data that was modified after it was signed: it must be rejected
  • Send legitimate data with a correct HMAC or signature: it must be accepted
  • Send data signed with the wrong key: it must be rejected
  • Re-scan with the security scanner to confirm the issue is resolved

Common Vulnerable Patterns

  • Accepting unsigned cookies or tokens
  • Not verifying JWT signatures
  • Using encryption without authentication
  • Trusting client-provided data
  • Missing HMAC verification

Additional Resources