Offensive security assessments

Cross-Site Request Forgery (CSRF)

Why it matters

Cross-Site Request Forgery (CSRF) is an attack that tricks a user into executing unwanted actions on a web application where they are authenticated. By exploiting the trust that a website has in the user's browser, an attacker can perform actions on behalf of the user without their consent. - Web applications that rely on cookies for authentication. - Forms that perform state-changing actions (e.g., updating email, password changes, making payments). - Applications with no CSRF protection or weak implementation of CSRF tokens. - Websites that do not enforce the SameSite attribute in cookies. 1. Check for CSRF tokens: Inspect requests using browser dev tools or a proxy ( our testing workflow) to see if CSRF tokens are used. 2. Modify request methods: Try changing POST requests to GET if CSRF tokens are only checked on certain methods. 3. Test Referer header validation: Remove or modify the Referer header to see if the request still goes through. 4. Craft a CSRF attack page: Create an HTML form that submits a malicious request and check if the action executes. 5. Look for cookie-based protections: Check for SameSite cookie attributes and test for bypasses. - Unauthorized actions on a victim’s account (e.g., changing email, modifying account details). - Financial fraud (e.g., transferring money, purchasing items without consent). - Privilege escalation if used to modify user roles. - Data leakage if sensitive actions can be triggered. - Use CSRF Tokens: Implement server-side generated CSRF tokens that are validated on each request. - Enforce SameSite Cookies: Set SameSite=Strict or SameSite=Lax to prevent cross-origin request execution. - Check Referer Headers: Validate the Referer or Origin header to ensure requests originate from trusted sources. - Use Secure Authentication Methods: Implement multi-factor authentication (MFA) to reduce CSRF impact. - Implement CAPTCHAs: Require user interaction (e.g., CAPTCHA) on critical actions to prevent automated CSRF attacks. - Using GET instead of POST (if the server only checks method type) - Removing or modifying CSRF tokens - Leveraging SameSite cookie misconfigurations - Exploiting Referer header validation weaknesses - Finding open redirects to trick the server into executing a malicious request - Utilizing JSONP endpoints or CORS misconfigurations

How we test it

Our operators follow a structured checklist for this topic, adapted to your API surface and authentication model.

Testing approach

Simple create CSRF HTML and done.
Change the request method, i.e., POST to GET.
Remove the CSRF parameter and its values.
Get CSRF token from user first and don't use the token.
Craft CSRF token in CSRF form including the captured token and send.
Get the CSRF token from first user and don't use it. This time CSRF key is also present. CSRF token and CSRF key are bound.

What we look for

Simple create CSRF HTML and done.
Change the request method, i.e., POST to GET.
Remove the CSRF parameter and its values.
Get CSRF token from user first and don't use the token.
Craft CSRF token in CSRF form including the captured token and send.
Get the CSRF token from first user and don't use it. This time CSRF key is also present. CSRF token and CSRF key are bound.

Related topics

Topic	Summary
Application Logic Flaws	Application Logic Flaws occur when a web application's normal logic or workflow can be manipulated, allowing attackers to bypass security measures or misuse functionality in unexpected ways.
Arbitrary Cookie Flags	Cookies that hold session or sensitive data are set without the proper security flags (Secure, HttpOnly, SameSite). This lets cookies travel over cleartext, be read by JavaScript, or be sent on cross-site requests, enabling theft and CSRF.
Back Button Attack	After a user logs out (or on a shared device), pressing the browser Back button or reopening cached pages reveals sensitive data or restores an authenticated view. This happens when the server lets responses be cached and does not fully invalidate the session.
Broken Authentication	Flaws in how an application confirms a user's identity, letting attackers compromise passwords, tokens, or sessions and assume other users' identities. It is one of the highest-impact web risks (OWASP Top 10: Identification and Authentication Failures).
Brute Force Attack	An attacker systematically tries many credentials, tokens, or values until one works. It succeeds when an endpoint lacks rate limiting, lockout, or sufficient secret entropy.
Captcha Bypass	A CAPTCHA is meant to block automated requests, but flawed implementation lets attackers skip or solve it programmatically. Bypassing it re-enables brute force, spam, and other automation the control was meant to stop.