CWE · MITRE source
CWE-650Trusting HTTP Permission Methods on the Server Side
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.
Last updated: 04 July 2026 00:28 UTC
Cumulative inbound coverage
How completely the frameworks we cross-walk collectively cover this — the verdict is the strongest single mapping (overlapping partials are not summed); breadth shows the corroboration behind it.
Collective: mostly · 4 mapping(s) from 2 framework(s): ASVS 5.0 3 (mostly) · ATT&CK 1 (partial)
NIST 800-53 r5 controls that address this weakness (0)AI
| Control | Title | Family | Why it addresses this CWE |
|---|---|---|---|
| No NIST controls proposed yet. | |||
MITRE ATT&CK techniques this weakness enables
Our own two-way CWE↔ATT&CK cross-walk — a direct mapping with no public source (the CWE→CAPEC→ATT&CK chain leaves most top weaknesses, incl. XSS and SQLi, mapped to nothing). Drafted by Grok and spot-checked by Claude Opus 4.8.
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial).
Top CVEs of this weakness type, ranked by Risk Priority
| CVE | Risk | CVSS | EPSS | Published |
|---|---|---|---|---|
CVE-2024-28787 UPD | 5.5 | 8.7 | 0.0081 | 2024-04-04 |
CVE-2025-21120 UPD | 5.5 | 8.3 | 0.0026 | 2025-08-04 |
CVE-2026-44548 UPD | 5.5 | 8.1 | 0.0012 | 2026-05-12 |
CVE-2022-38115 | 3.5 | 5.3 | 0.0065 | 2022-11-23 |
CVE-2023-50327 | 3.5 | 5.3 | 0.0049 | 2024-02-02 |
CVE-2024-45097 | 3.5 | 5.9 | 0.0031 | 2024-09-05 |
CVE-2024-45098 | 3.5 | 6.8 | 0.0035 | 2024-09-05 |
CVE-2024-45282 | 3.5 | 4.3 | 0.0029 | 2024-10-08 |
CVE-2026-42543 UPD | 3.5 | 4.3 | 0.0017 | 2026-06-04 |
CVE-2024-56339 UPD | 1.5 | 3.7 | 0.0037 | 2025-08-07 |