CSRF
# Index
# Description
# Understanding CSRF
# How CSRF attack works?
# Why CSRF is dangerous?
# CSRF vs XSS?
# Preventing CSRF
# CSRF in OWASP
# Description:
Cross-Site Request Forgery (CSRF) is a web security vulnerability that tricks an authenticated user into performing unintended actions on a web application. Unlike attacks that steal data directly, CSRF abuses the trust a website places in a user's browser. If a user is already logged in, an attacker may be able to make requests on their behalf without their knowledge.
# Understanding CSRF
Most web applications use cookies to identify authenticated users.
For example:
- User logs into a banking website.
- The browser stores a session cookie.
- Every future request automatically includes that cookie.
The website assumes the request is legitimate because it comes from an authenticated session.
A CSRF attack exploits this trust.
# How CSRF attack works?
Imagine a user is logged into their online banking account.
The banking website provides an endpoint: POST /transfer-money
A legitimate request may transfer money to another account.
An attacker creates a malicious webpage containing:
<form action="https://bank.com/transfer-money" method="POST">
<input type="hidden" name="amount" value="10000">
<input type="hidden" name="recipient" value="attacker">
</form>
<script>
document.forms[0].submit();
</script>
If the victim visits the attacker's page while logged into the bank:
- The form submits automatically.
- The browser includes the victim's session cookie.
- The bank believes the request came from the user.
- The transaction executes.
The victim never intended to perform the action.
# Why is CSRF Dangerous?
CSRF can allow attackers to:
- Change account settings
- Transfer funds
- Modify email addresses
- Change passwords
- Submit forms
- Perform administrative actions
- Purchase products
- Delete data
Any action that relies solely on session cookies may be vulnerable.
Real-World Example
Imagine a social media platform that allows users to change their email address.
An attacker sends a victim a seemingly harmless link.
Behind the scenes, the page automatically submits: POST /change-email
The user's email is changed to one controlled by the attacker.
The attacker may then reset the victim's password and take over the account.
# CSRF vs XSS
These vulnerabilities are often confused.
CSRF
- Exploits user trust
- Uses authenticated sessions
- Tricks users into performing actions
- Does not require code execution in the victim's browser
XSS
- Injects malicious scripts
- Executes code in the victim's browser
- Can steal cookies and credentials
- May be used to launch CSRF attacks
In fact, a successful XSS vulnerability can often bypass CSRF protections.
# Preventing CSRF
Use CSRF Tokens
This is the most common defense.
The server generates a unique random token and embeds it within forms.
Example: <input type="hidden" name="csrf_token" value="random-token">
When the form is submitted, the server verifies the token.
Attackers cannot easily guess or generate valid tokens.
Use SameSite Cookies
Modern browsers support the SameSite attribute.
Example: Set-Cookie: session=abc123; SameSite=Strict
This helps prevent cookies from being sent with cross-site requests.
Verify Origin and Referer Headers
Applications can verify where requests originate.
Requests coming from unexpected domains can be rejected.
Require Re-authentication
For sensitive actions such as:
- Password changes
- Financial transfers
- Account deletion
Require users to re-enter credentials or complete multi-factor authentication.
Use POST Instead of GET
Sensitive operations should never be performed through GET requests.
Poor way: GET /delete-account
Better way: POST or DELETE /delete-account
CSRF in Modern Applications
Modern frameworks provide built-in CSRF protection.
Examples include:
- Django
- Laravel
- Ruby on Rails
- Spring Security
- ASP.NET
However, developers must ensure these protections remain enabled and correctly configured.
# CSRF in OWASP
Cross-Site Request Forgery has long been recognized by OWASP as a significant web application security risk.
Although modern frameworks have reduced its prevalence, improperly configured applications can still be vulnerable.
Organizations should continue implementing CSRF protections as part of their secure development practices.
Article Metadata:
Published Date: 2026-06-15
Updated Date: 2026-06-15
About the Author: Team absequ is a group of engineers and researchers working on real-world systems, software development, and technology solutions.
Further Reading: