CWE - CWE-472: External Control of Assumed-Immutable Web Parameter (4.18)

Home > CWE List > CWE-472: External Control of Assumed-Immutable Web Parameter (4.18)

CWE Glossary Definition

CWE-472: External Control of Assumed-Immutable Web Parameter

Weakness ID: 472

Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.

View customized information:

For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.

Edit Custom Filter

Description

The web application does not sufficiently verify inputs that are assumed to be immutable but are actually externally controllable, such as hidden form fields.

Extended Description

If a web product does not properly protect assumed-immutable values from modification in hidden form fields, parameters, cookies, or URLs, this can lead to modification of critical data. Web applications often mistakenly make the assumption that data passed to the client in hidden fields or cookies is not susceptible to tampering. Improper validation of data that are user-controllable can lead to the application processing incorrect, and often malicious, input.

For example, custom cookies commonly store session data or persistent data across sessions. This kind of session data is normally involved in security related decisions on the server side, such as user authentication and access control. Thus, the cookies might contain sensitive data such as user credentials and privileges. This is a dangerous practice, as it can often lead to improper reliance on the value of the client-provided cookie by the server side application.

Alternate Terms

Assumed-Immutable Parameter Tampering

Common Consequences

Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

Impact	Details
Modify Application Data	Scope: Integrity Without appropriate protection mechanisms, the client can easily tamper with cookies and similar web data. Reliance on the cookies without detailed validation can lead to problems such as SQL injection. If you use cookie values for security related decisions on the server side, manipulating the cookies might lead to violations of security policies such as authentication bypassing, user impersonation and privilege escalation. In addition, storing sensitive data in the cookie without appropriate protection can also lead to disclosure of sensitive user data, especially data stored in persistent cookies.

Impact

Details

Modify Application Data

Scope: Integrity

Without appropriate protection mechanisms, the client can easily tamper with cookies and similar web data. Reliance on the cookies without detailed validation can lead to problems such as SQL injection. If you use cookie values for security related decisions on the server side, manipulating the cookies might lead to violations of security policies such as authentication bypassing, user impersonation and privilege escalation. In addition, storing sensitive data in the cookie without appropriate protection can also lead to disclosure of sensitive user data, especially data stored in persistent cookies.

Potential Mitigations

Phase(s)	Mitigation
Implementation	Strategy: Input Validation Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Implementation	Strategy: Input Validation Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.

Phase(s)

Mitigation

Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."

Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Implementation

Strategy: Input Validation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.

Relationships

Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

Relevant to the view "Research Concepts" (View-1000)

Nature	Type	ID	Name
ChildOf	Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	471	Modification of Assumed-Immutable Data (MAID)
ChildOf	Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	642	External Control of Critical State Data
CanFollow	Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	656	Reliance on Security Through Obscurity

Relevant to the view "Software Development" (View-699)

Nature	Type	ID	Name
MemberOf	Category Category - a CWE entry that contains a set of other entries that share a common characteristic.	19	Data Processing Errors

Relevant to the view "Architectural Concepts" (View-1008)

Nature	Type	ID	Name
MemberOf	Category Category - a CWE entry that contains a set of other entries that share a common characteristic.	1019	Validate Inputs

Modes Of Introduction

Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

Phase	Note
Implementation	OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.

Applicable Platforms

Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Demonstrative Examples

Example 1

In this example, a web application uses the value of a hidden form field (accountID) without having done any input validation because it was assumed to be immutable.

(bad code)

Example Language: Java

String accountID = request.getParameter("accountID");
User user = getUserFromID(Long.parseLong(accountID));

Example 2

Hidden fields should not be trusted as secure parameters.

An attacker can intercept and alter hidden fields in a post to the server as easily as user input fields. An attacker can simply parse the HTML for the substring:

(bad code)

Example Language: HTML

<input type="hidden"

or even just "hidden". Hidden field values displayed later in the session, such as on the following page, can open a site up to cross-site scripting attacks.

Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference	Description
CVE-2002-0108	Forum product allows spoofed messages of other users via hidden form fields for name and e-mail address.
CVE-2000-0253	Shopping cart allows price modification via hidden form field.
CVE-2000-0254	Shopping cart allows price modification via hidden form field.
CVE-2000-0926	Shopping cart allows price modification via hidden form field.
CVE-2000-0101	Shopping cart allows price modification via hidden form field.
CVE-2000-0102	Shopping cart allows price modification via hidden form field.
CVE-2000-0758	Allows admin access by modifying value of form field.
CVE-2002-1880	Read messages by modifying message ID parameter.
CVE-2000-1234	Send email to arbitrary users by modifying email parameter.
CVE-2005-1652	Authentication bypass by setting a parameter.
CVE-2005-1784	Product does not check authorization for configuration change admin script, leading to password theft via modified e-mail address field.
CVE-2005-2314	Logic error leads to password disclosure.
CVE-2005-1682	Modification of message number parameter allows attackers to read other people's messages.

Detection Methods

Method	Details
Automated Static Analysis	Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.) Effectiveness: High

Method

Details

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

Memberships

Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.

Nature	Type	ID	Name
MemberOf	CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.	715	OWASP Top Ten 2007 Category A4 - Insecure Direct Object Reference
MemberOf	CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.	722	OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOf	CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.	991	SFP Secondary Cluster: Tainted Input to Environment
MemberOf	CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.	1348	OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOf	CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.	1403	Comprehensive Categorization: Exposed Resource

Vulnerability Mapping Notes

Usage ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason Acceptable-Use

Rationale

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

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.

Notes

Relationship

This is a primary weakness for many other weaknesses and functional consequences, including XSS, SQL injection, path disclosure, and file inclusion.

Theoretical

This is a technology-specific MAID problem.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
PLOVER	Web Parameter Tampering
OWASP Top Ten 2007	A4	CWE More Specific	Insecure Direct Object Reference
OWASP Top Ten 2004	A1	CWE More Specific	Unvalidated Input

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-146	XML Schema Poisoning
CAPEC-226	Session Credential Falsification through Manipulation
CAPEC-31	Accessing/Intercepting/Modifying HTTP Cookies
CAPEC-39	Manipulating Opaque Client-based Data Tokens

References

[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 4: Use of Magic URLs, Predictable Cookies, and Hidden Form Fields." Page 75. McGraw-Hill. 2010.

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 17, "Embedding State in HTML and URLs", Page 1032. 1st Edition. Addison Wesley. 2006.

Content History

Submissions
Submission Date	Submitter	Organization
2006年07月19日 (CWE Draft 3, 2006年07月19日)	PLOVER
2006年07月19日 (CWE Draft 3, 2006年07月19日)
Modifications
Modification Date	Modifier	Organization
2023年06月29日	CWE Content Team	MITRE
2023年06月29日	updated Mapping_Notes
2023年04月27日	CWE Content Team	MITRE
2023年04月27日	updated Detection_Factors, Relationships
2021年10月28日	CWE Content Team	MITRE
2021年10月28日	updated Relationships
2020年06月25日	CWE Content Team	MITRE
2020年06月25日	updated Potential_Mitigations
2020年02月24日	CWE Content Team	MITRE
2020年02月24日	updated Potential_Mitigations, Relationships
2019年06月20日	CWE Content Team	MITRE
2019年06月20日	updated Related_Attack_Patterns, Relationships
2019年01月03日	CWE Content Team	MITRE
2019年01月03日	updated Related_Attack_Patterns
2017年11月08日	CWE Content Team	MITRE
2017年11月08日	updated Applicable_Platforms, Demonstrative_Examples, Modes_of_Introduction, Relationships
2015年12月07日	CWE Content Team	MITRE
2015年12月07日	updated Relationships
2014年07月30日	CWE Content Team	MITRE
2014年07月30日	updated Relationships
2012年05月11日	CWE Content Team	MITRE
2012年05月11日	updated Demonstrative_Examples, References, Relationships
2011年06月27日	CWE Content Team	MITRE
2011年06月27日	updated Common_Consequences
2011年06月01日	CWE Content Team	MITRE
2011年06月01日	updated Common_Consequences
2011年03月29日	CWE Content Team	MITRE
2011年03月29日	updated Potential_Mitigations
2010年12月13日	CWE Content Team	MITRE
2010年12月13日	updated Description
2010年04月05日	CWE Content Team	MITRE
2010年04月05日	updated Related_Attack_Patterns
2009年10月29日	CWE Content Team	MITRE
2009年10月29日	updated Common_Consequences, Demonstrative_Examples, Description, Other_Notes, Relationship_Notes, Theoretical_Notes
2009年07月27日	CWE Content Team	MITRE
2009年07月27日	updated Potential_Mitigations
2009年01月12日	CWE Content Team	MITRE
2009年01月12日	updated Relationships
2008年09月08日	CWE Content Team	MITRE
2008年09月08日	updated Description, Relationships, Other_Notes, Taxonomy_Mappings
2008年07月01日	Eric Dalci	Cigital
2008年07月01日	updated Potential_Mitigations, Time_of_Introduction
2008年07月01日	Sean Eidemiller	Cigital
2008年07月01日	added/updated demonstrative examples
Previous Entry Names
Change Date	Previous Entry Name
2008年04月11日	Web Parameter Tampering

More information is available — Please edit the custom filter or select a different filter.

Page Last Updated: September 09, 2025

MITRE

Use of the Common Weakness Enumeration (CWE™) and the associated references from this website are subject to the Terms of Use. CWE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). Copyright © 2006–2025, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation.

HSSEDI