Description
View on MITREStrategy: Libraries or Frameworks Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [ REF-1482 ]. For example, use anti-CSRF packages such as the OWASP CSRFGuard. [ REF-330 ] Another example is the ESAPI Session Management control, which includes a component for CSRF. [ REF-45 ]
Ensure that the application is free of cross-site scripting issues ( CWE-79 ), because most CSRF defenses can be bypassed using attacker-controlled script.
Generate a unique nonce for each form, place the nonce into the form, and verify the nonce upon receipt of the form. Be sure that the nonce is not predictable ( CWE-330 ). [ REF-332 ] Note: Note that this can be bypassed using XSS ( CWE-79 ).
Identify especially dangerous operations. When the user performs a dangerous operation, send a separate confirmation request to ensure that the user intended to perform that operation. Note: Note that this can be bypassed using XSS ( CWE-79 ).
Use the "double-submitted cookie" method as described by Felten and Zeller: When a user visits a site, the site should generate a pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. Because of the same-origin policy, an attacker cannot read or modify the value stored in the cookie. To successfully submit a form on behalf of the user, the attacker would have to correctly guess the pseudorandom value. If the pseudorandom value is cryptographically strong, this will be prohibitively difficult. This technique requires Javascript, so it may not work for browsers that have Javascript disabled. [ REF-331 ] Note: Note that this can probably be bypassed using XSS ( CWE-79 ), or when using web technologies that enable the attacker to read raw headers from HTTP requests.
Do not use the GET method for any request that triggers a state change.
Check the HTTP Referer header to see if the request originated from an expected page. This could break legitimate functionality, because users or proxies may have disabled sending the Referer for privacy reasons. Note: Note that this can be bypassed using XSS ( CWE-79 ). An attacker could use XSS to generate a spoofed Referer, or to generate a malicious request from a page whose Referer would be allowed.
No detection method information available for this CWE.
No examples or observed CVEs available for this CWE.
CWE-352: CWE-352: Cross-Site Request Forgery (CSRF) is a Common Weakness Enumeration (CWE) entry maintained by MITRE. Description
Yes. CWE-352 ranked #5 in the CWE Top 25 for 2024, associated with 345 CVEs that year. The CWE Top 25 highlights the most common and impactful software weaknesses based on real-world vulnerability data.
If exploited, CWE-352 (CWE-352: Cross-Site Request Forgery (CSRF)) it can compromise Gain Privileges or Assume Identity, Bypass Protection Mechanism, Read Application Data, Modify Application Data, DoS: Crash and Exit, leading to outcomes such as Scope: Confidentiality, Integrity, Availability, Non-Repudiation, Access Control The consequences will vary depending on the nature of the functionality that is vulnerable to CSRF. An attacker could trick a client into making an unintentional request to the web server via a URL and image load.
Recommended mitigations for CWE-352 include: Strategy: Libraries or Frameworks Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [ REF-1482 ]. For example, use anti-CSRF packages such as the OWASP CSRFGuard. [ REF-330 ] Another example is the ESAPI Session Management control, which includes a component for CSRF. [ REF-45 ] Ensure that the application is free of cross-site scripting issues ( CWE-79 ), because most CSRF defenses can be bypassed using attacker-controlled script. Generate a unique nonce for each form, place the nonce into the form, and verify the nonce upon receipt of the form. Be sure that the nonce is not predictable ( CWE-330 ). [ REF-332 ] Note: Note that this can be bypassed using XSS ( CWE-79 ).
CWE-352 commonly affects Languages. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.
A CWE (Common Weakness Enumeration) like CWE-352 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.
Search for vulnerabilities that exploit CWE-352
See how this weakness ranks against others
Understanding vulnerabilities vs weaknesses
How vulnerability severity is measured
Complete technical details and references