With more web security threats emerging daily, modern developers and security professionals can’t afford to overlook the ongoing threat posed by cross-site request forgery (CSRF) attacks.
CSRF attacks trick users into performing unintended actions that give attackers access to protected systems. Relying on outdated assumptions about how CSRF works can lead to missteps and open the door to serious data breaches.
Many web applications rely on tools such as third-party scripts, AI-enhanced personalization engines, and cross-origin functionality to deliver dynamic content, enhance user experience, and enable integrated services.
CSRF web attacks target authenticated sessions within a user’s web application browser. They manipulate a browser’s functionality by issuing unauthorized HTTP requests to a server. These web attacks use existing session credentials, such as session IDs, tokens, and cookies.
Instead of stealing data directly, hackers use CSRF to prompt users to take unwanted actions that unintentionally create software vulnerabilities. As with social engineering, the victim of the attack has no idea what’s happening. Bad actors rely on the same-origin policy, which causes session cookies to be automatically included in web browser HTTP requests.
For example, an attacker might embed an image tag or JavaScript snippet into an email. If the user clicks it, they unknowingly send a request to the target site that includes their session cookies. Because the user is authenticated, the server considers the request legitimate and processes it as a valid POST request without requiring additional validation.
Because CSRF attacks require minimal user interaction, they often go undetected, making them particularly dangerous. Even though a cookie might be marked as Secure or HttpOnly, it still gets automatically attached by a browser. Using them without additional backup security measures is insufficient to protect against CSRF.
For example, a cyber attacker could use a forged HTTP request to change a user’s email address or modify configuration settings whenever the user logs in. Even seemingly harmless GET requests can trigger sensitive actions if the application doesn’t enforce method restrictions or CSRF checks.
Developers often assume that setting basic cookie flags or relying on browser policies is sufficient. But modern web applications require more deliberate defense mechanisms, such as:
Without proper server-side validation, any application could be vulnerable to CSRF exploits. To prevent significant damage, systems must be designed with this threat in mind.
The best way to understand how dangerous CSRF attacks can be is to examine a common scenario that hackers often use. The following illustrates how CSRF succeeds when inadequate protections are in place around a web application.
A user decides to log into their online bank account to check their current balance. They go to the URL https://mybank.com and enter their credentials. After verifying the entered credentials, the bank site creates a new user session, which is tracked by a secure cookie. Here’s how it looks from a code perspective:
Set-Cookie: sessionID=pdqr5678; Secure; HttpOnly; SameSite=None
The cookie is stored and automatically included in subsequent requests to the same URL. People often fail to properly log out after performing an online action. For example, the user leaves the tab open after verifying their checking account balance, meaning their session remains active and open to a CSRF attack.
After leaving the banking site, the user checks their email and sees an email offering a discount on a pair of earbuds they’ve been eying. The user clicks the link in the email, which directs them to the site https://bigdiscounts.com. Unbeknownst to the user, the site is malicious and contains a hidden CSRF payload.
Below is an example of a hidden HTML form designed to target the user’s banking site:
<body onload="document.forms[0].submit()">
<form action="https://mybank.com/transfer" method="POST">
<input type="hidden" name="to" value="hackerexternalaccount" />
<input type="hidden" name="amount" value="7500" />
</form>
</body>
When the user’s browser tries to load the above form, their previously validated session cookie gets included. That means https://mybank.com believes the action is legitimate because the browser issued the original cookie. The browser cannot distinguish a forged request from a legitimate one. It simply sends the session cookie because the domain matches. This is how all browsers behave unless specifically restricted.
Many modern browsers allow users to block third-party cookies or apply strict SameSite policies. Without those protections, malicious requests are treated as valid.
Once the user’s banking site receives the request with a valid cookie, it confirms that the user is logged in. If no other verification methods exist, the site looks at the transfer request and attempts to process it, assuming it’s a legitimate, state-changing request. The user is entirely unaware that they’ve just submitted a request to transfer $7,500 from their bank account because of the CSRF.
Web applications typically rely on state-changing operations within an authenticated user session, making them vulnerable to CSRF. This also applies to functions designed to update user data, modify system state, or perform other sensitive operations. Rather than exploiting code vulnerabilities, CSRF takes advantage of web applications’ trust in a user’s browser.
HTTP POST, PUT, and DELETE requests are often exploited when they perform operations such as:
Many frameworks, such as ASP.NET Core, offer built-in CSRF protections, but they must be correctly configured. Common mistakes include:
Anti-CSRF mechanisms should always be used to distinguish legitimate from forged requests. Poor cookie configuration increases risk:
SameSite attribute: SameSite=None permits cross-site requests and can increase vulnerability without other safeguards.Secure or HttpOnly flags: Unmarked cookies can be intercepted (if sent over HTTP) or accessed via JavaScript.The consequences of a successful CSRF attack can be severe, ranging from unauthorized account changes to full-scale data breaches:
The following are a few recent examples of CSRF incidents and their consequences.
Recently, a critical flaw in the Ruby on Rails framework was discovered where its CSRF protection could be bypassed, exposing applications to unauthorized state-changing requests. As a result, attackers could perform actions for authenticated users, such as changing account settings or executing transactions, compromising user data, and application integrity.
A CSRF vulnerability (CVE‑2025‑32354) in Zimbra Collaboration Suite’s GraphQL endpoint allowed attackers to execute unauthorized operations like modifying contacts, changing account settings, and exfiltrating emails without user interaction. With over 200,000 organizations at risk, this flaw enabled full account takeover and data theft until it was patched in Zimbra 10.1.4.
In March 2025, a CSRF vulnerability (CVE‑2025‑27624) in Jenkins allowed malicious actors to toggle side panel widget states via GET requests and inject arbitrary identifiers into user profiles. These types of incidents could pave the way for persistent UI manipulation or stored XSS attacks. Jenkins fixed the issue in versions 2.500 and 2.492.2 by requiring POST requests and enforcing CSRF validation.
Below are some effective security best practices that developers and security teams can use to protect applications.
CSRF tokens are unpredictable, unique values typically generated per session or request and tied to a user’s authenticated state. They’re included with every state-changing request and validated server-side. If the token doesn’t match what’s expected, the request is rejected, thus blocking unauthorized actions triggered by forged requests.
The SameSite cookie attribute restricts whether cookies are sent with cross-origin requests. It offers three modes:
Secure flag and should be used only when necessary (e.g., third-party integrations).Reinforce sensitive workflows by requiring users to explicitly confirm their actions. This can include double password entry, one-time passcodes (OTPs), CAPTCHAs, or confirmation dialogs. In essence, the goal is to add friction that automated CSRF exploits can’t bypass.
Check Origin and Referer headers on incoming HTTP requests to confirm they come from trusted sources. For example, a request to https://mybank.com/transfer should have a matching origin header from https://mybank.com. Note that some privacy settings and browser extensions can strip or block these headers, so this technique should be used as part of a layered security strategy, not as a standalone defense.
While CSRF and cross-site scripting (XSS) are both serious security threats, they operate in fundamentally different ways.
XSS allows attackers to inject malicious executable code (typically JavaScript) into a webpage viewed by another user. This can be used to hijack sessions, log keystrokes, or redirect users to malicious sites.
By contrast, CSRF manipulates a user’s browser into sending unauthorized requests without their knowledge. While XSS exploits the user’s trust in a website, CSRF exploits the website’s trust in the user’s browser. Importantly, CSRF attackers cannot see responses or interact directly with applications, but they can still force state-changing actions, like changing a password or submitting a form.
Both attack types undermine core pillars of trust in web applications. CSRF can result in unauthorized transactions or account changes, while XSS may lead to data theft, malware injection, or session compromise.
| Aspect | CSRF | XSS |
| Attack Method | Tricks the browser into sending unauthorized requests | Injects malicious code (usually JavaScript) into a webpage |
| Trust Exploited | Website’s trust in the user/browser | Users’ trust in the website |
| Attacker Capabilities | Cannot see responses or interact directly | Can read data, steal cookies, hijack sessions, etc. |
| Common Consequences | Unauthorized transactions, changed settings | Data theft, session hijacking, and malware injection |
| User Interaction | Requires the user to be authenticated and perform an action | Can be triggered just by visiting a malicious or compromised page |
Let’s look at CSRF protections offered by popular development frameworks. These built-in protections make it easier to enforce CSRF defenses without starting from scratch.
ValidateAntiForgeryToken attribute to controller actions forces POST, PUT, and DELETE requests to carry a valid token. {%csrf_token%} tag automatically embeds a token in a form. The framework then performs validations upon each form submission. protect_from_forgery directive to controllers enforces request validation. Built-in protections in frameworks are a strong start, but they’re not a complete defense. CSRF attacks exploit trusted sessions at the browser level, and attackers often combine them with reverse engineering or code tampering to find deeper weaknesses in your application.
At the foundation, make sure your defenses include adding CSRF tokens, validating request headers, configuring SameSite cookies, and prompting user actions. These are essential for verifying request authenticity and minimizing the risk of unauthorized actions within trusted sessions.
You can also strengthen your defense even further and harden your application from the inside out with PreEmptive. PreEmptive’s app protection tools add layers of security that complement server-side defenses, including:
Together, these protections help reduce the risk of exploits like CSRF and strengthen your app’s overall security posture. Request your free trial of PreEmptive today and see how layered defenses can protect your applications from even the most deceptive threats.