CWE-650: Trusting HTTP Permission Methods on the Server Side

VariantIncompleteExploit Likelihood: High

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.

View on MITRE
Back to CWE Lookup

Extended Description

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.

Technical Details

Structure
Simple
Vulnerability Mapping
ALLOWED

Applicable To

Languages
Not Language-Specific
Platforms

Source-backed guidance

Additional facts reviewed against primary or authoritative security sources.

Verify controls for CWE-650 with SSDF evidence

Use NIST SSDF verification and vulnerability-response practices to detect CWE-650, Trusting HTTP Permission Methods on the Server Side, throughout the product lifecycle. Derive review questions, static or dynamic checks, and negative tests from the CWE's causal behavior; define the components and lifecycle stages each check covers; and retain findings with enough evidence to distinguish the root cause from symptoms and impacts. Track escapes and false negatives, then improve the verification plan after every confirmed occurrence.

NIST SP 800-218 Secure Software Development Framework — National Institute of Standards and Technology

Address Trusting HTTP Permission Methods on the Server Side during System Configuration

MITRE associates mitigation with System Configuration; recorded impacts include Gain Privileges or Assume Identity, Modify Application Data, and Read Application Data; related weaknesses include CWE-436. Use these source-defined anchors to turn CWE-650 into implementation, review, and verification checks for the affected component.

CWE-650: Trusting HTTP Permission Methods on the Server Side — MITRE CWE

Triage CWE-650 against known exploitation evidence

Use CISA's Known Exploited Vulnerabilities catalog to test whether a vulnerability mapped to CWE-650, Trusting HTTP Permission Methods on the Server Side, has evidence of exploitation in the wild. Confirm the CVE-to-CWE root-cause mapping independently before attaching the example, then capture the affected product, required action, and remediation deadline. A missing KEV match is not evidence that the weakness is unexploited, and a KEV entry must not be generalized to every occurrence of this CWE.

Known Exploited Vulnerabilities Catalog — Cybersecurity and Infrastructure Security Agency

Apply precise root-cause mapping to CWE-650

Apply MITRE's full root-cause mapping guidance when using CWE-650, Trusting HTTP Permission Methods on the Server Side. Separate weakness language from attacker prerequisites and technical impact, check the entry's abstraction and vulnerability-mapping notes, and prefer the most specific Base or Variant supported by the evidence. Record the rejected alternatives and require an independent review before the mapping is used for remediation trends or program metrics.

CVE to CWE Root Cause Mapping Guidance — MITRE CWE

Validate CWE-650 with root-cause mapping checks

Apply MITRE's root-cause mapping quick tips to CWE-650, Trusting HTTP Permission Methods on the Server Side. Confirm the finding describes the causal weakness rather than an impact or attack pattern, compare the abstraction and mapping notes with plausible alternatives, and have a second reviewer challenge the selection. Preserve the evidence and reasoning so recurring defects can be measured against one consistent identifier.

CVE to CWE Root Cause Mapping Quick Tips — MITRE CWE

Frequently Asked Questions

What is CWE-650: Trusting HTTP Permission Methods on the Server Side?+

CWE-650: Trusting HTTP Permission Methods on the Server Side is a Common Weakness Enumeration (CWE) entry maintained by MITRE. 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.

What are the security consequences of Trusting HTTP Permission Methods on the Server Side?+

If exploited, CWE-650 (Trusting HTTP Permission Methods on the Server Side) it can compromise Access Control, Integrity and Confidentiality, leading to outcomes such as Gain Privileges or Assume Identity, Modify Application Data and Read Application Data.

How do you prevent or mitigate Trusting HTTP Permission Methods on the Server Side?+

Recommended mitigations for CWE-650 include: Configure ACLs on the server side to ensure that proper level of access control is defined for each accessible resource representation.

Which programming languages are affected by Trusting HTTP Permission Methods on the Server Side?+

CWE-650 commonly affects Not Language-Specific. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.

What is the difference between a CWE and a CVE?+

A CWE (Common Weakness Enumeration) like CWE-650 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.

Learn More

Find Related CVEs

Search for vulnerabilities that exploit CWE-650

CVE vs CWE: What's the Difference?

Understanding vulnerabilities vs weaknesses

Understanding CVSS Scoring

How vulnerability severity is measured

View Full MITRE Entry

Complete technical details and references

Advertisement