In a CSRF attack, the attacker controls a malicious webpage. When an authenticated victim visits that page, it causes the victim's browser to send an unintended state-changing request to the target application. If the browser includes the victim's authentication credentials and the application doesn't have effective CSRF protections, the server may accept the request and perform the action.
- State changing Requests
Attacker-controlled page ↓ Victim's browser ↓ Authenticated request ↓ Target application ↓ State changes
- CSRF Token
- SameSite Cookies
- Origin / Referer validation
- Basic Application Reconnaissance
Start from the homepage and identify functionality that can change server-side data.
Look for:
Login/logout Change email Change password Profile update Account settings Address/contact changes File upload Payment or transaction actions Create/delete/update functions Administrative actions
- Identify Forms and Input Points
For each relevant page, inspect: HTML
elements Form action Form method Input names Hidden fields Submit buttons JavaScript event handlers- Inspect the Source Code
Look for CSRF-related mechanisms:
csrf csrfToken _token authenticity_token xsrf
Also check whether the application uses:
Hidden CSRF fields JavaScript-generated tokens Meta-tag tokens Cookies such as CSRF-related cookies
- Intercept the HTTP Request
Use Burp Proxy and perform the action normally. Now you have the baseline legitimate request.
- Analyze the HTTP Request
Inspect both headers and body.
Headers
Pay particular attention to: Cookie Origin Referer Content-Type Sec-Fetch-Site Sec-Fetch-Mode
Body
Identify: State-changing parameters CSRF token Hidden parameters IDs User-controlled values
- Determine Whether CSRF Protection Exists
Classify the request:
A. No CSRF token email=test@example.com Potential CSRF vulnerability.
B. CSRF token exists email=test@example.com&csrf=ABC123 Continue testing the token's implementation.
- Test the CSRF Token
If a token exists, test its properties in an authorized environment.
Check whether:
Token is required Missing token is rejected Invalid token is rejected Token can be reused Token is tied to the user's session Token changes appropriately Token from another session/account is rejected Token validation is consistent across request methods
This is where several CSRF weaknesses can appear.
- Test HTTP Method Handling
Determine whether the application supports different methods for the same action.
For example: POST /change-email
Test whether the application improperly accepts: GET /change-email?email=test@example.com
If a state-changing action works through GET without appropriate CSRF protection, that's a significant finding.
- Test Cross-Origin Behavior
For an authorized test, determine whether the request can be triggered from another origin.
Consider whether the application relies on: CSRF tokens SameSite cookies Origin validation Referer validation
The important question is: "Can an attacker-controlled page cause the victim's browser to perform this state-changing request?"
- Build a Safe CSRF PoC
Once you've identified a suspected vulnerability, create a non-destructive proof of concept using a harmless test value.
For a simple POST-based case:
<script> document.forms[0].submit(); </script>For an authorized lab or test environment, host the PoC on your exploit server and verify whether the request is executed using the authenticated session.
- Verify the Impact
Confirm whether the server-side state actually changed.
For example: Before: victim@example.com
CSRF request ↓
After: csrf-test@example.com
Don't rely only on a 200 OK or redirect. Verify the actual state change.
- Document the Finding
Record: Vulnerable functionality Endpoint HTTP method Parameters Authentication mechanism CSRF protection present/absent Token behavior PoC Evidence Impact Severity Remediation
Homepage ↓ Map application functionality ↓ Find state-changing actions ↓ Inspect forms/source code ↓ Capture HTTP request ↓ Analyze headers + body ↓ Identify CSRF protection ↓ Test token validation ↓ Test session/token binding ↓ Test HTTP method handling ↓ Test cross-origin request behavior ↓ Create safe PoC ↓ Verify state change ↓ Document finding
When testing CSRF, keep asking these four questions: What action changes server-side state? What prevents another website from triggering that action? Is that protection actually enforced? Can I demonstrate the issue safely with a PoC?
That gives you a reusable methodology for testing email changes, password changes, profile updates, account settings, and other state-changing functionality.