I have a JavaScript web application that communicates with an API on a different subdomain. The HTML and Javascript are all hosted in S3.

A conventional CSRF token is put into the body of the HTML page and either used by a form or read by JavaScript; but as the HTML is statically hosted this isn't possible in my case.

Is it safe to request a CSRF token from the server during application startup with an AJAX request? The resulting token could then be attached as a header to all of the future requests to the API.

Is there a better solution to protecting against CSRF attacks in my architecture?


Yes so long as you observe the usual precautions; request it once at the start of the session then keep it within the application, secure the api request with SSL, ensure the token is created properly (cyrptographically strong random, or encrypted claims etc)

There's more information on the OWASP page on CSRF prevention here: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#General_Recommendations_For_Automated_CSRF_Defense


You actually don't need token , you can make this using a custom header .

I know that CSRF-Token is important because I am a bug bounty hunter but you can depend on the browser security instead . I saw many cases when the CSRF-Token get leaked from the subdomain .

For example when you send data from a.mysite.com include this header :

Ok-Request: 1 

Since you send data to cross domain you should configure your HTTP header Just like this (for b.mysite.com):

Access-Control-Allow-Headers: x-requested-with, content-type, accept, origin, Ok-Request 
Access-Control-Allow-Methods: GET, POST, PUT, OPTIONS
Access-Control-Allow-Origin: a.mysite.com

When the browser will send custom header it will make An OPTION request first if everything is okay like (Origin , Method ,Headers) then the real request will be made . Otherwise the browser will throw a SOP error .

Not the answer you're looking for? Browse other questions tagged or ask your own question.