This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. Specifically, manual analysis can be useful for finding this weakness, and for minimizing false positives assuming an understanding of business logic. However, it might not achieve desired code coverage within limited time constraints. For black-box analysis, if credentials are not known for privileged accounts, then the most security-critical portions of the application may not receive sufficient attention. Consider using OWASP CSRFTester to identify potential issues and aid in manual analysis.
CWE-352 Compound Stable
Cross-Site Request Forgery (CSRF)
Cross-Site Request Forgery (CSRF) happens when a web application cannot reliably tell if a user actually intended to submit a request, allowing an attacker to trick a user's browser into performing…
Definition
What is CWE-352?
Cross-Site Request Forgery (CSRF) happens when a web application cannot reliably tell if a user actually intended to submit a request, allowing an attacker to trick a user's browser into performing unwanted actions on their behalf.
Imagine you're logged into your bank's website in one tab. In another tab, you click a malicious link or visit a booby-trapped site. That malicious page can silently send a request to your bank's site—like a funds transfer—using your existing, logged-in session. Because your browser automatically includes your session cookies, the bank sees the request as legitimate and coming from you, even though you never intended to send it.
To prevent this, applications must verify that state-changing requests (like logins, transfers, or profile updates) are deliberate. The most common and effective defense is to use anti-CSRF tokens: unique, secret values embedded in forms or requests that the server validates. Other protections include checking the `Origin` or `Referer` headers for same-origin requests, or requiring re-authentication for sensitive operations. Without these guards, attackers can exploit a user's trust in a site to perform actions without their consent.
Real-world impact
Real-world CVEs caused by CWE-352
-
Add user accounts via a URL in an img tag
-
Add user accounts via a URL in an img tag
-
Arbitrary code execution by specifying the code in a crafted img tag or URL
-
Gain administrative privileges via a URL in an img tag
-
Delete a victim's information via a URL or an img tag
-
Change another user's settings via a URL or an img tag
-
Perform actions as administrator via a URL or an img tag
-
modify password for the administrator
How attackers exploit it
Step-by-step attacker path
- 1
This example PHP code attempts to secure the form submission process by validating that the user submitting the form has a valid session. A CSRF attack would not be prevented by this countermeasure because the attacker forges a request through the user's web browser in which a valid session already exists.
- 2
The following HTML is intended to allow a user to update a profile.
- 3
profile.php contains the following code.
- 4
This code may look protected since it checks for a valid session. However, CSRF attacks can be staged from virtually any tag or HTML construct, including image tags, links, embed or object tags, or other attributes that load background images.
- 5
The attacker can then host code that will silently change the username and email address of any user that visits the page while remaining logged in to the target web application. The code might be an innocent-looking web page such as:
Vulnerable code example
Vulnerable HTML
The following HTML is intended to allow a user to update a profile.
<form action="/url/profile.php" method="post">
<input type="text" name="firstname"/>
<input type="text" name="lastname"/>
<br/>
<input type="text" name="email"/>
<input type="submit" name="submit" value="Update"/>
</form> Attacker payload
The attacker can then host code that will silently change the username and email address of any user that visits the page while remaining logged in to the target web application. The code might be an innocent-looking web page such as:
<SCRIPT>
function SendAttack () {
form.email = "attacker@example.com";
```
// send to profile.php*
form.submit();}
</SCRIPT>
<BODY onload="javascript:SendAttack();">
<form action="http://victim.example.com/profile.php" id="form" method="post">
<input type="hidden" name="firstname" value="Funny">
<input type="hidden" name="lastname" value="Joke">
<br/>
<input type="hidden" name="email">
</form> Secure code example
Secure pseudo
// Validate, sanitize, or use a safe API before reaching the sink.
function handleRequest(input) {
const safe = validateAndEscape(input);
return executeWithGuards(safe);
} What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Prevention checklist
How to prevent CWE-352
- Architecture and Design 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]
- Implementation Ensure that the application is free of cross-site scripting issues (CWE-79), because most CSRF defenses can be bypassed using attacker-controlled script.
- Architecture and Design 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]
- Architecture and Design 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.
- Architecture and Design 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]
- Architecture and Design Do not use the GET method for any request that triggers a state change.
- Implementation 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.
Detection signals
How to detect CWE-352
CSRF is currently difficult to detect reliably using automated techniques. This is because each application has its own implicit security policy that dictates which requests can be influenced by an outsider and automatically performed on behalf of a user, versus which requests require strong confidence that the user intends to make the request. For example, a keyword search of the public portion of a web site is typically expected to be encoded within a link that can be launched automatically when the user clicks on the link.
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Bytecode Weakness Analysis - including disassembler + source code weakness analysis Binary Weakness Analysis - including disassembler + source code weakness analysis
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Web Application Scanner
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Fuzz Tester Framework-based Fuzzer
Plexicus auto-detects CWE-352 and opens a fix PR in under 60 seconds.
Codex Remedium scans every commit, identifies this exact weakness, and ships a reviewer-ready pull request with the patch. No tickets. No hand-offs.
Frequently asked questions What is CWE-352?
How serious is CWE-352?
What languages or platforms are affected by CWE-352?
How can I prevent CWE-352?
How does Plexicus detect and fix CWE-352?
Where can I learn more about CWE-352?
Frequently asked questions
What is CWE-352?
Cross-Site Request Forgery (CSRF) happens when a web application cannot reliably tell if a user actually intended to submit a request, allowing an attacker to trick a user's browser into performing unwanted actions on their behalf.
How serious is CWE-352?
MITRE rates the likelihood of exploit as Medium — exploitation is realistic but typically requires specific conditions.
What languages or platforms are affected by CWE-352?
MITRE lists the following affected platforms: Web Server.
How can I prevent CWE-352?
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.
How does Plexicus detect and fix CWE-352?
Plexicus's SAST engine matches the data-flow signature for CWE-352 on every commit. When a match is found, our Codex Remedium agent opens a fix PR with the corrected code, tests, and a one-line summary for the reviewer.
Where can I learn more about CWE-352?
MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/352.html. You can also reference OWASP and NIST documentation for adjacent guidance.
Related weaknesses
Weaknesses related to CWE-352
CWE-345 Parent
Insufficient Verification of Data Authenticity
This vulnerability occurs when an application fails to properly check where data comes from or confirm its legitimacy, allowing untrusted…
CWE-1293 Sibling
Missing Source Correlation of Multiple Independent Data
This vulnerability occurs when a system trusts a single source of data without verification, making it impossible to detect if that source…
CWE-346 Sibling
Origin Validation Error
This vulnerability occurs when an application fails to properly confirm the true origin of incoming data or communication, allowing…
CWE-347 Sibling
Improper Verification of Cryptographic Signature
This vulnerability occurs when an application fails to properly check the digital signature on data, or skips the verification step…
CWE-348 Sibling
Use of Less Trusted Source
This vulnerability occurs when a system has access to multiple sources for the same critical data, but it chooses to rely on the less…
CWE-349 Sibling
Acceptance of Extraneous Untrusted Data With Trusted Data
This vulnerability occurs when a system processes both trusted and untrusted data together, but fails to separate them. The application…
CWE-351 Sibling
Insufficient Type Distinction
This vulnerability occurs when an application fails to properly differentiate between different types of data or objects, leading to…
CWE-353 Sibling
Missing Support for Integrity Check
This vulnerability occurs when a system uses a communication protocol that lacks built-in integrity verification, such as a checksum or…
CWE-354 Sibling
Improper Validation of Integrity Check Value
This vulnerability occurs when software fails to properly check the integrity of data by validating its checksum or hash value. Without…
Resources
Further reading
- MITRE — official CWE-352 https://cwe.mitre.org/data/definitions/352.html
- Cross-Site Request Forgeries (Re: The Dangers of Allowing Users to Post Images) https://marc.info/?l=bugtraq&m=99263135911884&w=2
- Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
- Cross-Site Request Forgeries: Exploitation and Prevention https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.147.1445
- CSRF - The Cross-Site Request Forgery (CSRF/XSRF) FAQ https://www.cgisecurity.com/csrf-faq.html
- Cross-site request forgery https://en.wikipedia.org/wiki/Cross-site_request_forgery
Ready when you are
Don't Let Security
Weigh You Down.
Stop choosing between AI velocity and security debt. Plexicus is the only platform that runs Vibe Coding Security and ASPM in parallel — one workflow, every codebase.