Author: Kateryna Ivanenko, Invicti Brand Manager
What is CSRF?
Cross-Site Request Forgery (CSRF) is a type of web application attack where an attacker forces the browser of an authenticated user to execute an unwanted action on a trusted website.
They create an external resource (e.g. a website, forum post) that sends a request to the target site on behalf of the user.
Because the browser automatically attaches authentication cookies, the server cannot determine whether the request is legitimate or forged.
As a result, attackers can force the execution of serious actions: changing passwords, updating email addresses, transferring funds, modifying account settings, etc.
If the targeted user has administrative privileges, the attack may lead to full compromise of the web application.
How to Protect Against CSRF: Key Methods
Below are the most effective CSRF prevention techniques recommended by OWASP and other authoritative sources.
1. Anti-CSRF Tokens
The most widely recommended method.
When generating an HTML form, the server creates a unique, unpredictable and cryptographically strong token. It is bound to the user/session, and validated server-side. Upon receiving the request, the server checks whether the token matches the one stored for the user session.
Every form or state-changing request (e.g., POST, changing settings, transferring funds) must include a CSRF token. If it is absent — the request should be blocked.
This can be implemented using either:
- Stateful tokens (stored on the server)
- Stateless tokens (signed tokens or HMAC-based)
GET must not be used for state-changing actions.
2. SameSite Cookie Policy and Secure Cookie Settings
Limit sending session cookies only when the request comes from the same site (SameSite=strict or lax).
This significantly complicates CSRF attempts originating from external websites.
Even if CSRF tokens are not implemented, the SameSite cookie policy adds an extra security layer, though it is not a complete solution to the problem.
3. Checking HTTP Headers
Verify the Origin or Referer headers to ensure the request originates from the expected domain.
Modern protection also includes using Fetch Metadata headers (Sec-Fetch-Site, Sec-Fetch-Mode, etc.), allowing the server to determine whether the request comes from the same site or from an external context.
4. Custom Headers for AJAX / API Requests
For AJAX or API endpoints that modify state, applications can require custom headers (e.g., X-Requested-With or others) and validate them on the server.
Browsers do not allow external sites to send custom headers without CORS (Cross-Origin Resource Sharing), so this blocks most cross-site requests.
Though, if CORS policy is too permissive, this mitigation can be weakened.
5. Use Frameworks/Libraries With Built-In CSRF Protection
Most modern frameworks include CSRF protection out of the box. It is advised to use them rather than writing your own implementation.
If your framework lacks built-in protection, you can add a library or module.
Testing Websites for CSRF
Security testing is an important part of overall strategy, since it can let you know for sure that your website is truly protected from CSRF.
It can be done via static analysis (SAST) and black-box testing (DAST).
- SAST finds vulnerabilities directly in code, allowing you to scan the whole codebase. Quick engine of Mend SAST can be used for this purpose.
- DAST safely imitates attacker’s actions on running websites to uncover vulnerabilities, like hackers would in real circumstances. Invicti (based on Acunetix and Netsparker) can also confirm findings to increase accuracy and save time.
If you want to test Invicti DAST or Mend SAST for free, please leave your contact details below, and we will get in touch with you within business hours:
