Improper Enforcement of Message Integrity During Transmission in a Communication Channel
This weakness occurs when software sends sensitive data over a communication channel without verifying that the message hasn't been altered in transit. An…
This weakness occurs when software sends sensitive data over a communication channel without verifying that the message hasn't been altered in transit. An attacker positioned between the sender and receiver can intercept and modify the data without detection, compromising confidentiality and authenticity. This is distinct from encryption alone — even encrypted data can be modified if integrity checks are absent.
02How It Happens
Communication integrity relies on cryptographic signatures or message authentication codes (MACs) that prove a message hasn't been tampered with. When software omits these checks, it assumes the channel is trustworthy or that encryption alone is sufficient. In reality, an attacker with network access (via man-in-the-middle positioning, DNS hijacking, or compromised infrastructure) can intercept packets, modify their contents, and forward them onward. The receiver has no way to detect the alteration because no integrity proof was included with the message.
This is especially dangerous when the modified data triggers critical actions — changing a payment amount, altering user permissions, or injecting malicious instructions into a configuration update.
03Real-World Impact
Undetected message modification can lead to unauthorized transactions, privilege escalation, data corruption, or injection of malware into software updates. For example, if an API response containing user permissions is modified in transit without integrity verification, an attacker could elevate their own privileges. If a firmware update is intercepted and altered, devices could be compromised at scale. The attacker leaves no obvious trace because the application accepts the modified data as legitimate.
Why it's vulnerable: The message is sent in plaintext (or even if encrypted) without any integrity check. An attacker on the network can intercept and modify the JSON payload — for example, changing the balance value — and the receiver will process the altered data without detecting the tampering.
Why it's vulnerable: The message is sent without a signature or MAC. Even over HTTPS, if the endpoint doesn't verify message integrity, a compromised intermediary or a man-in-the-middle attacker can modify the JSON before it reaches the server.
Use authenticated encryption or explicit MACs. Include an HMAC or digital signature with every message containing sensitive data; verify it on receipt before processing.
Never rely on encryption alone. Encryption protects confidentiality but not integrity. Always add a separate integrity mechanism.
Use TLS/HTTPS with certificate pinning. Enforce encrypted, authenticated channels; validate server certificates to prevent man-in-the-middle attacks.
Implement request signing for APIs. Sign API requests with a shared secret or private key; validate the signature server-side before accepting the payload.
Rotate and protect shared secrets. Store HMAC keys and signing keys securely; rotate them regularly and never hardcode them in source code.
Log and alert on integrity failures. Detect and log any message that fails integrity verification; treat repeated failures as a potential attack.
06Signs You May Already Be Affected
Monitor for unexpected changes to critical data (user permissions, account balances, configuration values) that occur without corresponding audit logs or user actions. Check application logs for integrity verification failures or rejected messages. If you observe data corruption or unauthorized modifications that correlate with network traffic patterns, integrity checks may be missing.