CWE-345: Insufficient Verification of Data Authenticity
Overview
Insufficient verification of data authenticity occurs when applications don't validate that data hasn't been tampered with during storage or transmission, accepting unsigned data, not verifying signatures/MACs, or trusting unauthenticated sources, enabling data tampering, message forgery, and MITM attacks.
OWASP Classification
A08:2025 - Software or Data Integrity Failures
Risk
High: Missing authenticity checks enable message tampering, forged API requests, modified cookies/tokens, corrupted file uploads, MITM attacks, replay attacks, and acceptance of malicious data as legitimate. Encryption alone doesn't 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 in your code
- Review the flaw details to identify the specific file, line number, and code pattern where data authenticity is not verified
- Identify what data lacks authentication: cookies, tokens, API messages, file uploads, database records, configuration data
- Determine the data source: client-provided, external API, file storage, database
- Trace the data flow to understand where and how unauthenticated data is accepted and used
Use message authentication codes (Primary Defense)
- HMAC-SHA256 for message authentication: Generate
HMAC-SHA256(secret_key, message)and include it with the message; verify HMAC before trusting data - AES-GCM (encryption + authentication): Provides both confidentiality and integrity in a single operation; use for encrypted data that needs tampering protection
- ChaCha20-Poly1305: Alternative to AES-GCM, faster on systems without AES hardware acceleration; provides authenticated encryption
- Verify MAC before using data: Always validate the MAC/authentication tag before processing or trusting the data; reject if verification fails
Implement digital signatures for critical data
- RSA signatures (2048+ bits): Use RSA-PSS or PKCS#1 v1.5 for signing critical data; verify signature with public key before trusting
- ECDSA (256+ bits): More efficient than RSA; use P-256, P-384 curves for signing; faster verification
- Ed25519 (modern, secure): Modern signature algorithm with strong security guarantees and fast performance
- Verify signatures on critical data: Always verify digital signatures on software updates, configuration files, API responses, contracts
Use authenticated encryption
- AES-GCM (encrypts and authenticates): Single operation provides both confidentiality and integrity; prevents tampering even with encryption
- ChaCha20-Poly1305: Modern authenticated encryption; good for mobile and systems without AES acceleration
- NOT AES-CBC alone (no authentication): AES-CBC only encrypts; doesn't prevent tampering; attacker can modify ciphertext
- Reject if authentication tag invalid: If the authentication tag doesn't verify, reject the entire message
Validate data integrity checks
- Check HMAC on received messages: Compute expected HMAC and compare with provided value using constant-time comparison
- Verify digital signatures on downloads: Verify software updates, documents, files using signature verification before installation/use
- Validate JWT signatures: Always verify JWT signature using correct algorithm and public key; reject "alg=none" tokens
- Use TLS for transport (provides authenticity): TLS provides transport-level authentication; use for API communication
Test the authenticity verification fix
- Verify unauthenticated data is now rejected (try sending message without HMAC/signature, should fail)
- Test with tampered data: Modify authenticated data and verify it's rejected
- Test with valid authentication: Ensure legitimate data with correct HMAC/signature is accepted
- Test with wrong keys: Verify data signed with wrong key is rejected
- Re-scan with security scanner to confirm the issue is resolved
Dynamic Scan Guidance
For guidance on remediating this CWE when detected by dynamic (DAST) scanners:
- Dynamic Scan Guidance - Analyzing DAST findings and mapping to source code
Common Vulnerable Patterns
- Accepting unsigned cookies/tokens
- Not verifying JWT signatures
- Using encryption without authentication
- Trusting client-provided data
- Missing HMAC verification