True, CSRF is not as common nowadays, but it doesn’t mean it’s not harmful to a web app or website. On the contrary, it can cause big problems for your business and your users. The prominent examples include damaged customer relationships, unauthorised fund transfers, etc.
Moreover, the reason for its removal from the top list is the growing awareness for handling this vulnerability in apps/sites. That said, CSRF vulnerability can be handled and mitigated in the popular web frameworks, thanks to the anti-CSRF techniques offered by top web frameworks — both frontend and backend.
However, those anti-CSRF measures don’t work on-the-fly. You must activate those security measures and follow the required steps to ensure your web app is protected against CSRF attacks. So, let’s learn about those measures.
But before we dive into the details of the security measures offered by the top web frameworks, let’s understand the common method to prevent CSRFs.
The common anti-CSRF technique
As outlined in the CSRF Prevention Cheat Sheet, token-based mitigation is the most popular (aka common) technique for preventing CSRFs. Let’s understand the basic logic behind this mitigation technique, i.e., how it works.
The web server sends a random text (called “CSRF Token”), which gets stored in a cookie. The client reads the cookie and sends the token in a header. The server compares the token in the header with the stored token. If they don’t match, it rejects the request made by the client, thus preventing a CSRF attack.
Cyber security vulnerabilities: What’s causing them and what can be done?
Why does it work? All web browsers implement a feature named “same-origin policy”. It restricts a website to read the cookies saved by another website or create custom request headers for another website. So, it prevents other sites to read the token set by a website. That’s the reason this method works.
Anti-CSRF Measures in Web Frameworks
Let’s discuss the anti-CSRF techniques introduced in the top web frameworks. This post covers the measures in two frontend web frameworks (Angular and React) and three backend web frameworks (Django, Express, and Laravel).
Angular is an open-source, popular frontend framework developed by Google. It offers its own set of user interface components that work across devices and platforms known as “Angular Material”. Angular Ivy — its latest version previewed in May 2019 — introduces easy-to-read code, faster build time, and more.
Angular packs the common security measure of reading the CSRF token called “XSRF-TOKEN” and setting a custom header named “X-XSRF-TOKEN”. But, it’s not the best news — you hardly need to do anything to get it working for you. It’s a de facto feature of its HttpClient, about which you can read more here.
However, it’s just a client-side framework, so your web server must support this protective method as well, i.e., it must send the random text (CSRF token) to the client. Moreover, it must check the incoming web requests for the given header (“X-XSRF-TOKEN”) and verify it with the stored token to mitigate CSRFs.
Django is a free and open-source backend framework based on Python. The web framework focuses on reusability of code and pluggability of modules along with low coupling and rapid development principles. It’s the webserver for some well-known websites such as Disqus, Bitbucket, Instagram, and Mozilla.
Django offers middleware for protecting a web server against CSRF attacks. The middleware must be activated in your project. Also, you must include the csrf_token tag inside the form elements which point to any in-project URL. If you’re looking for more details or its support for AJAX, check this page.
Express is a free and open-source backend web framework for Node.js that’s fast, flexible, as well as minimalistic. Its modular design allows developers to add new features using plugins per requirements of the project. It’s so popular that it’s mostly used as the de facto web server framework for Node.js.
Since Express is a minimalistic web framework, it doesn’t support any anti-CSRF measure by default (unlike Angular). But it provides a pluggable middleware (like Django) that helps your webserver to protect itself against CSRF attacks.
The middleware is known as “csurf”, and it’s super-easy to set up in your project. It offers some bootstrap options as well to configure its functionality. In case you’re looking for more details on it or some example code, visit this page.
Laravel is a free and open-source web framework for PHP — the most common programming language for web development. It supports a modular packaging system (like Express) and offers numerous utilities to ease the development and maintenance of web applications including its syntactic sugar feature.
It provides middleware named VerifyCsrfToken from its web middleware group that auto-verifies the token in the incoming web requests and disregards CSRF-based requests. It’s easy to use — just include @csrf directive in your forms to include the token field. You can check its docs for more information.
React is a free front-end framework developed by Facebook for building user interfaces. It’s mostly used for developing mobile or single-page apps. It doesn’t provide a default security measure against CSRF attacks, unlike Angular.
Hence, you must introduce a security solution in your app as well as your web server shall support it. For example, @dbillinghamuk shared a post detailing anti-CSRF protection using Express.js as the server and React as the client.
That said, it’s easy to implement as well. You only require reading the stored CSRF token in your React app and generate relevant headers to send along with the request to the server. And the server will quarantine all CSRF requests. Of course, it’s not as easy to do as in Angular since the latter supports it natively.