Missing Support for Integrity Check

The software uses a transmission protocol that does not include a mechanism for verifying the integrity of the data during transmission, such as a checksum.


If integrity check values or "checksums" are omitted from a protocol, there is no way of determining if data has been corrupted in transmission. The lack of checksum functionality in a protocol removes the first application-level check of data that can be used. The end-to-end philosophy of checks states that integrity checks should be performed at the lowest level that they can be completely implemented. Excluding further sanity checks and input validation performed by applications, the protocol's checksum is the most important level of checksum, since it can be performed more completely than at any previous level and takes into account entire messages, as opposed to single packets.


The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.

Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.

Example One

In this example, a request packet is received, and privileged information is sent to the requester:

while(true) {
  DatagramPacket rp = new DatagramPacket(rData,rData.length);
  InetAddress IPAddress = rp.getAddress();
  int port = rp.getPort();
  out = secret.getBytes();
  DatagramPacket sp =new DatagramPacket(out, out.length, IPAddress, port);

The response containing secret data has no integrity check associated with it, allowing an attacker to alter the message without detection.

See Also

Data Integrity Issues

Weaknesses in this category are related to a software system's data integrity components. Frequently these deal with the ability to ensure the integrity of data, such ...

Verify Message Integrity

Weaknesses in this category are related to the design and architecture of a system's data integrity components. Frequently these deal with ensuring integrity of data, ...

SFP Secondary Cluster: Protocol Error

This category identifies Software Fault Patterns (SFPs) within the Protocol Error cluster.

Comprehensive CWE Dictionary

This view (slice) covers all the elements in CWE.

Weaknesses without Software Fault Patterns

CWE identifiers in this view are weaknesses that do not have associated Software Fault Patterns (SFPs), as covered by the CWE-888 view. As such, they represent gaps in...

CWE Cross-section

This view contains a selection of weaknesses that represent the variety of weaknesses that are captured in CWE, at a level of abstraction that is likely to be useful t...

Common Weakness Enumeration content on this website is copyright of The MITRE Corporation unless otherwise specified. Use of the Common Weakness Enumeration and the associated references on this website are subject to the Terms of Use as specified by The MITRE Corporation.