The server contains a protection mechanism that assumes that any URI that is accessed using HTTP GET will not cause a state change to the associated resource. This might allow attackers to bypass intended access restrictions and conduct resource modification and deletion attacks, since some applications allow GET to modify state.
The HTTP GET method and some other methods are designed to retrieve resources and not to alter the state of the application or resources on the server side. Furthermore, the HTTP specification requires that GET requests (and other requests) should not have side effects. Believing that it will be enough to prevent unintended resource alterations, an application may disallow the HTTP requests to perform DELETE, PUT and POST operations on the resource representation. However, there is nothing in the HTTP protocol itself that actually prevents the HTTP GET method from performing more than just query of the data. Developers can easily code programs that accept a HTTP GET request that do in fact create, update or delete data on the server. For instance, it is a common practice with REST based Web Services to have HTTP GET requests modifying resources on the server side. However, whenever that happens, the access control needs to be properly enforced in the application. No assumptions should be made that only HTTP DELETE, PUT, POST, and other methods have the power to alter the representation of the resource being accessed in the request.

Primary

Architecture and Design

Implementation

Operation

High

Access Control
Gain Privileges or Assume Identity
An attacker could escalate privileges.

Integrity
Modify Application Data
An attacker could modify resources.

Confidentiality
Read Application Data
An attacker could obtain sensitive information.

System Configuration
Configure ACLs on the server side to ensure that proper level of access control is defined for each accessible resource representation.

Allowed
This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Evgeny Lebanidze
Cigital
2008-01-30
Draft 8
2008-01-30

CWE Content Team
MITRE
2008-09-08
updated Common_Consequences, Relationships

CWE Content Team
MITRE
2008-10-14
updated Description, Enabling_Factors_for_Exploitation

CWE Content Team
MITRE
2009-10-29
updated Common_Consequences

CWE Content Team
MITRE
2011-03-29
updated Common_Consequences

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences

CWE Content Team
MITRE
2012-05-11
updated Relationships

CWE Content Team
MITRE
2012-10-30
updated Potential_Mitigations

CWE Content Team
MITRE
2014-07-30
updated Relationships

CWE Content Team
MITRE
2017-01-19
updated Relationships

CWE Content Team
MITRE
2017-11-08
updated Applicable_Platforms, Description, Enabling_Factors_for_Exploitation, Observed_Examples, Relationships

CWE Content Team
MITRE
2020-02-24
updated Relationships

CWE Content Team
MITRE
2021-10-28
updated Relationships

CWE Content Team
MITRE
2023-04-27
updated Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Applicable_Platforms, Weakness_Ordinalities