1. Support Center
  2. Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) allows an attacker to carry out actions in a different security context such as another, logged in user. Read here, how you can efficiently fix a CSRF vulnerability.

Security Assessment



Vulnerability Information

This type of attack, also known as CSRF or XSRF, Cross-Site Reference Forgery, Hostile Linking, and more, allows an attacker to carry out actions (requests) within an application where a user is currently logged in. It is “cross-site” or “cross-origin” because it uses different websites or elements to interfere, i.e., to send requests within an application that originate from outside of the application.

A CSRF sends an HTTP request whenever a user opens a website containing malicious code to achieve its aim. The code is embedded in such a way that no further actions by the user are required. 

This kind of attack is widely used in spam emails. By clicking on a malicious URL, the attack starts without the user’s knowledge and forges actions. The HTTP requests sent without the user’s knowledge may access, modify or delete sensitive data.

While CSRF attacks mainly occur through users’ browsers, they can effectively be executed through any file that allows scripting, including word and XML documents, RSS feeds, and more. 

Prevention Guide

To prevent CSRF injection attacks, you must make sure that an attacker cannot craft an arbitrary request run in the security context of any other user and send from a different website. This is one of the main conditions that need to be in place for a CSRF attack to be successful. Disrupting this condition prevents the possibility of such an attack.

Token-based prevention

As stated by the OWASP Cross-Site Request Forgery Prevention Cheat Sheet, the most common mitigation technique for cross-site request forgery attacks is using a CSRF token (also known as a synchronizer token or anti-CSRF token). These session tokens are unpredictable and unique values generated by the application and sent to the client. After that, they are sent back in the request made by the client to the server, which verifies the request. 

This introduces an unknown element that can effectively defuse the CSRF attack. Any request that does not originate from the original form will not include the correct value for the CSRF token and can be easily discarded. 

Common CSRF token vulnerabilities

Yet, some vulnerabilities can arise in the use of CSRF tokens due to omissions in the procedure. The most common CSRF token vulnerabilities include:

  • Tokens are validated and used only when POST requests are made and not when GET requests are made
  • Validation occurs only if the session token is present, and if it is omitted, validation is also skipped
  • Tokens are not tied to the current user session but are compared to tokens issued at any point by the application
  • Tokens are tied to a cookie but not one that is used to track the current session
  • Applications do not maintain a record of tokens – instead, the token is included in the cookie and the application verifies that the token in the request is the same as the one in the cookie

All of the above constitute vulnerabilities that can open the door to a CSRF attack. To defend against such an attack, CSRF tokens need to be implemented correctly, along with several other mitigation techniques.

When using modern frameworks, tokens-based CSRF protection is typically included or can easily be added to forms and validated by the corresponding middleware. Furthermore, for single-page applications, the CSRF token may be provided by a meta tag which is then read from the JavaScript in the browser and amended to every request. 

Double-submit cookie prevention

A double-submit cookie token approach can be used if using a valid token on the server-side is impossible. In this cookie-based session handling, when a user visits a website, the site generates a value that stores as a cookie on the user’s device, apart from the cookie that serves as a session identifier.

When a legitimate request is submitted to the site, it must contain the same value as included in the cookie. The server then verifies this, and if the values match, the request parameter is accepted.

Same-site cookie prevention

As recommended by OWASP, this approach should be used together with a CSRF token strategy and not as a substitute. 

The same-site cookie approach restricts the origin from which a cookie can be sent. Thus, CSRF exploits the possibility of making a cross-origin request (and hence same-site cookies). By limiting requests so that they can only be sent from the origin to which a cookie is related, the ability to send external requests to an application is effectively prevented.

Custom request header

A technique that is particularly effective for AJAX or API endpoints is the use of custom request headers. In this approach, JavaScript is used to add a custom header. Unfortunately, JavaScript can’t make cross-origin requests with a custom header because of the SOP security restrictions.

This prevents sending a cross-domain request with custom headers, thereby eliminating the possibility of a CSRF attack.


Django is similarly easy to protect any form by a CSRF-Token using the snippet within the <form></form> tags.

  {% csrf_token %} 

To provide the token for use with JavaScript requests, retrieve it from its storage cookie and add it to the request.

var csrftoken = Cookies.get('csrftoken');
xhr.setRequestHeader("X-CSRFToken", csrftoken);

Please refer to the Django documentation for more detailed examples.


To protect forms in Laravel, include the following code within the <form></form>tags.

 {{ csrf_field() }} 

For JavaScript requests, the file resources/assets/js/bootstrap.js automatically configures the csrf-token meta tag, which the Axios HTTP library will use. If you are not using this library, check the Laravel documentation for more information.

For more information about Crashtest Security visit crashtest-security.com