What is a Cross-site request forgery attack (CSRF)? Web Security


A Cross-site request forgery (CSRF) is:


A common example is an <img> tag embedded in a malicious page with the src pointing to the attack’s target. For instance:

<!-- This is embedded in another domain's site -->
<img src="http://target.site.com/add-user?user=name&grant=admin">

The above <img> tag will send a http get request to target.site.com every time the page that contains it is loaded.

If the user had previously logged in to target.site.com and the site used a session cookie to keep the session active, this cookie will be sent as well.

If the target site does not implement any CSRF mitigation techniques, the request will be handled as a valid request on behalf of the user.

What is the problem?

If the user was logged in and the cookie were storing session information, the request will also be authenticated and made in the name of the user.

This request can be used to:

  • post messages on a forum under the user's name,
  • make purchases,
  • transfer money
  • or apply for a passport.

This is then important to verify that the request was made:

  • by the user intentionally,
  • rather than by another site tricking the user into making the request unknowingly.

How is the cross request performed?

This cross-origin http request is performed via:


Why this problem exists?

This problem exists because any HTTP requests can be sent from any other origins.

Any fetch HTML element (image, video, …) or a HTML form will create a HTTP request

How can I prevent a CSRF request?

Sites can prevent such attacks:

If session data are not stored as cookies, CSRF attacks are not possible.

Token (Headers, Meta)

A CSRF token is a random, hard-to-guess string aimed at protecting a form from a CSRF attack


  • the server generates for each served page (form) a random string, the CSRF token,
  • The CSRF token is added to the form as a hidden field
  • It's very difficult to guess the token and therefore it's difficult to submit a fake form.

The CSRF token is sent generally as an header called X-CSRF

The token may be stored:

<meta name="csrf-param" content="authenticity_token">
<meta name="csrf-token" content="glRwabjUEr/jI4ms0oM1jdxb0iG/iS3R0BEMWHTQsZbzNToWyd4PKbJ40Oexn5tno0Yt6c5zEBlHWmMZ3GOzKw==">

The token should not be stored:

  • in a cookie because the browser send always every cookie even with a cross origin request. The Cross Site request forgery exploit it but the cross-site scripting exploit also. Because an HTTP header is not automatically sent, the token is under control.


The origin is the cornerstone of the web security and you can:

  • check the origin value against the origin that created the session
  • and/or only allow some origin with CORS

Origin Header Check

The Origin HTTP headers can be checked against the value obtained when the session was created.

The Referer header may also be used.

The browser add it automatically but for server-side or native apps, the Origin header should be sent with an identifying URL as the value. Example:

curl -c cookie.txt \
   -d [email protected] \
   -d password=123 \
   -H "Origin: https://mywebsite.com" \
  • Use the session cookie to call your api
curl -b cookie.txt \
   -d '{"posts": [{"title": "Hello World"}]}' \
   -H "Content-Type: application/json" \
   -H "Origin: https://mywebsite.com" \


The cors setting can also prevent this kind of attack. It allows only request from some origin

Example with access-control-allow-origin

  • Request can be made by the browser for every domain
Access-Control-Allow-Origin: *  

  • Request can be made by the browser for only from the domain example.com
Access-Control-Allow-Origin: http://example.com 

On this site for instance, we allows that the fetching of resources from https://jsfiddle.net/ because it's where you can try our code live and this code sometimes fetch some resources such a json or csv file.

Access-Control-Allow-Origin: https://jsfiddle.net 

Use same site cookie to prevent sending along the cookie.


This method mitigates CSRF exploit against the the Oauth redirection URI

The client send pass a nonce parameter (called state in oauth) and the client validate that the the value coming from the response matches the one it sent.

This is mostly used in the two way authentication code flow method where the client gets a code via a redirection url and needs to ask an authorization point to transform it as authentication token.



Discover More
HTML - Image (Img tag)

img is an fetch element that represents an image. An image in HTML can also be represented with a picture element that defines logically the same image but may have different physical image (different...
HTML - Security (Secure applications)

This article is security when writing an application that shows HTML pages. HTMLHTTP security page HTML is a programming language that can download and run script. Therefore, you should be extremely...
HTML Form - 1001 ways to submit a Form and handle the corresponding Event

This page talks and shows all the ways on how to submit a form and handle the submit event in javascript. How a form can be submitted ? HTML One way is to include a input element of type submit that...
HTTP - Cross-Origin Request

A cross-origin request is a request that was not created by code (html page, javascript, ...)) of the same origin. cross site requestsame origin requestcross-originsame origin A page may contain images...
Cookie Devtool
How to manage Cookies in the Browser via Javascript?

This article is HTTP cookies management in the client side (browser) via javascript. Cookie are one way to store data in the browser. document.cookie is a property of the browser document that returns...
In OAuth, what is the state query parameter known as Local State?

The state query parameter is an opaque value used by the client (app) in redirection flow to maintain the state between the and (response) (ie to restore or continue the navigation of the user). ...
Web HTTP - SameSite Cookie property (First-Party-Only)

samesite is a cookie property that controls if a cookie should be sent along in a cross-site HTTP request ie: when the origin of the code (HTML, Javascript, ..) that created the request (generally the...
Web Security - Fake Form Submission (Signup,..)

Spam or fake form submissions can be made by: a bot (spambot) and a human Example of form: newsletter Sign-up Account Sign-up Comments ... Fake form submission happen due to bots that scour...
What are safe and unsafe requests?

In a HTTP security context, requests are: safe if they don't have a method that changes the state (ie GET, HEAD) unsafe otherwise (ie with the method POST, PATCH, PUT) When the type of request has...

Share this page:
Follow us:
Task Runner