When you research web application security you will come across Cross-Site Request Forgery (CSRF). This attack vector is taking advantage of cookies, but in a preventable way. In this post we’ll discuss what the attack is and how it can be prevented. We’ll also discuss Angular’s XSRF feature, which helps you prevent attack. It requires cooperation from your server, and we’ll explain what you need to do.

Note: Angular uses the acronym XSRF, but this is synonymous with CSRF.

What is Cross-Site Request Forgery (CSRF)?



Most attacks focus on stealing your cookies because nearly every website uses cookies as a form of authentication. The setup is this: when a user logs into your server, you set a cookie in the browser. This cookie contains a unique ID which is a link to the user’s session information in your database. The browser supplies this cookie on future requests, and the server knows who you are.

On the surface this sounds not-so-bad, but here is the catch: the web browser can be tricked into making requests to your server, even if the end-user didn’t perform the action themselves.

How is that possible? This attack exploits the default nature of the HTML parser in your browser. Imagine that you run a store at www.mystore.com . Your store has an API that allows users to make 1-click purchases. That API uses a URL that requires the user to be logged in (to have a cookie session), and looks like this:

http://www.mystore.com/buy?item=expensiveThing 1 2 http : //www.mystore.com/buy?item=expensiveThing

Now imagine that there is a malicious person that wants to exploit your Buy API and cause a headache for your users. This malicious person carries out their attack by making posts on websites and social media that contain an image link that looks like this:

<img src="http://www.mystore.com/buy?item=expensiveThing"/> 1 2 < img src = "http://www.mystore.com/buy?item=expensiveThing" / >

Now imagine a customer who is logged into your site, who is visiting one of the pages where this link has been placed. When their browser encounters this tag it will automatically makes a GET request to the URL (because it naively wants to show the picture to your customer). When it does this it automatically sends along the cookies for www.mystore.com with the request. Thus, the server thinks your customer is logged in and completes the 1-click purchase for the customer!

This is pretty disturbing, as the customer has no idea that this has happened – they are simply surfing the web as normal and aren’t aware that this request has been made.

CSRF Mitigations That Don’t Work

Before we get into the proper solutions for this problem, I want to enumerate two common approaches that don’t actually solve the problem. I mention these because I see these solutions on the interwebs, but they are wrong:

Using POST Requests . It is sometimes thought that using proper form-based POST requests will mitigate this attack, but that is not true. You can create a form on another website and point its action URL to your site, and the browser will do the same thing: make the malicious request, with cookies.

. It is sometimes thought that using proper form-based POST requests will mitigate this attack, but that is not true. You can create a form on another website and point its action URL to your site, and the browser will do the same thing: make the malicious request, with cookies. Using HTTP-Only or Secure cookies. While you definitely should use these flags on your session cookie, they don’t implicitly stop the attack: the browser still sends the cookies to your domain when a request is made to your domain. Your server does not know if this is a real user or an attack.

With that out of the way, let’s move on to the important discussion: how do we stop this for reals 🙂

How To Prevent CSRF

Preventing this attack requires a knowledge of where the request is coming from in the browser. We want to ensure that the request was triggered by an explicit action from a user who is using the JavaScript application on our website.

We can achieve this by relying on a set of rules that browsers respect, called the Same-Origin Policy. This policy asserts that certain sensitive operations are performed by JavaScript code that is running on our website, not some other website.

One of those operations is the ability to read cookies. While the browser will automatically supply your cookies for the domain of the request, there is one useful limitation: the JavaScript code that is running on a website cannot read the cookies of other websites. We can leverage this to create our CSRF solution.

Using a CSRF Token Cookie

Because JavaScript can only read cookies from our domain, we will store a second cookie on our domain that contains a unique token. This is the CSRF Token cookie. This cookie must be created when the user is logged in, and should contain a random, un-guessable string that is associated with the user’s session ID (for future lookups).

Every time the JavaScript application wants to make a request, it will need to read this token and send it along in a custom HTTP header. Because these operations (reading the cookie, setting the header) can only be done on the same domain of the JavaScript application, we can know that this is being done by a real user who is using our JavaScript application.

A passive image tag or malicious form post, on another site, would not be able to do these things. If your server sees a request that is missing the custom header, or the token in the header is not the one that is associated with the user’s session, your server should reject the request.

Leveraging Angular’s XSRF Feature

Angular packages the CSRF token approach, making it simpler for us to implement. For every request that your Angular application makes of your server, the Angular $http service will do these things automatically:

Look for a cookie named XSRF-TOKEN on the current domain.

on the current domain. If that cookie is found, it reads the value and adds it to the request as the X-XSRF-TOKEN header.

Thus the client-side implementation is handled for you, automatically! But this does leave the server side pieces in your hands. You will need to do the following parts:

During login: create the CSRF token (with a random, un-guessable string), and associate it with the user session. You will need to send it on the login response as the XSRF-TOKEN cookie.

cookie. Assert that all incoming requests to your API have the X-XSRF-TOKEN header, and that the value of the header is the token that is associated with the user’s session.

That’s it! With a little bit of backend work, you now have a strategy which protects you from CSRF attacks.

Go Forth and Secure All the Things!

My goal for this post is to demystify what CSRF is, and how Angular tries to help you with a solution. CSRF is just a small piece in the web-application security puzzle. For more information, please see the other posts that I have written on this subject:

Token Based Authentication for Single Page Apps (SPAs)

Build Secure User Interfaces Using JSON Web Tokens (JWTs)

-r out