Protect Your Angular App From Cross-Site Request Forgery

Protect Your Angular App From Cross-Site Request Forgery

Previously, I wrote about web security at a high level and the framework-agnostic ways to increase safety and mitigate vulnerabilities.

Posts in the SPA web security series
1. Defend Your SPA from Security Woes
2. Defend Your SPA from Common Web Attacks
3. Protect Your Angular App From Cross-Site Request Forgery
4. Protect Your Angular App From Cross-Site Scripting

Now, I want to dive a little deeper into the vulnerabilities. In this short post, we’ll dive into Cross-Site Request Forgery (CSRF) and look at the built-in help you get when using Angular.

Table of Contents

Cross-Site Request Forgery (CSRF) protection

In the previous post, you learned how an attack for CSRF occurs when an agitator uses your active session for a trusted site to perform unauthorized actions. We also learned there’s built-in support from browsers to mitigate attacks with SameSite attributes on cookies, validating the authenticity of the request on the backend, and potentially having the frontend send a CSRF token to the backend for every request.

The mitigation strategies primarily require server-side work, except for that game of CSRF token sending, where the client needs to send the token back in a way the backend can validate.

Giphy of a dog picking up mail from the postal worker

When using CSRF tokens, it’s essential to tie the token to the user’s session so that the backend can validate the request. The most common ways are through the patterns called Synchronizer Token Pattern and Double Submit Cookie.

Synchronizer Token Pattern

The Synchronizer Token Pattern requires the backend to store the user’s session information and match it up with the CSRF token for validity. This pattern can be used with SPAs but is a better match for web apps that use forms with post methods for requests, such as:

<form action="https://myfavekdramas.com/fave-form" method="POST">
  <label for="name">What is your favorite K-Drama?</label>
  <input type="text" id="name" name="name">
  <button>Save my favorite K-Drama</button>
</form> 

Submitting this form POSTs to https://myfavekdramas.com/fave-form using the application/x-www-form-urlencoded content type. CSRF is especially susceptible when using non-JSON data.

Sadly, this pattern doesn’t involve double the cookies—it’s a dual submission. Sad news indeed for chocolate-chip cookie fans. 🍪🍪 😢 But the good news is the Double Submit Cookie Pattern doesn’t require the backend to track the user’s session to the CSRF token.

In this pattern, the CSRF token is a separate cookie from the user’s session identifier. The client sends the CSRF token in every request, and the backend validates that the CSRF token cookie and the token in the request values match. This pattern is more common for SPAs.

CSRF support in Angular

Angular has built-in support for a flavor of the Double Submit Cookie Pattern, where the CSRF token is automatically added as an HTTP header for every backend request once you have a CSRF token in a cookie. Nice!

The HttpClientXsrfModule automatically adds an interceptor for your HTTP requests. The interceptor grabs the CSRF token from a session cookie named XSRF-TOKEN and adds the token value to outgoing requests in the HTTP header named X-XSRF-TOKEN. Then your backend is responsible for verifying the values for the cookie and HTTP header match.

To add this handy helper, add HttpClientModule and the HttpClientXsrfModule to your module’s imports array.

If you don’t like the default names, you have the option of configuring the names of the cookie and HTTP header like this:

imports: [
  HttpClientModule,
  HttpClientXsrfModule.withOptions({
    cookieName: 'Pecan-Sandies',
    headerName: 'Top-Of-Page'
  })
]

Learn more about CSRF and creating applications using Angular

Watch for the fourth and final post in this series, as we dive into Cross-Site Scripting (XSS) and learn how Angular’s built-in security mechanisms protect us.

Posts in the SPA web security series
1. Defend Your SPA from Security Woes
2. Defend Your SPA from Common Web Attacks
3. Protect Your Angular App From Cross-Site Request Forgery
4. Protect Your Angular App From Cross-Site Scripting

If you liked this post, you might be interested in these links.

Don’t forget to follow us on Twitter and subscribe to our YouTube channel for more great tutorials. We’d also love to hear from you! Please comment below if you have any questions or want to share what tutorial you’d like to see next.

Alisa Duncan is a Senior Developer Advocate at Okta, a full-stack developer, and a community builder who loves the thrill of learning new things. She is a Google Developer Expert in Angular and organizes coding workshops and community events locally and internationally. Her background is primarily working on enterprise software platforms, and she is a fan of all things TypeScript and JavaScript.

Okta Developer Blog Comment Policy

We welcome relevant and respectful comments. Off-topic comments may be removed.