Cross-site request forgery, or CSRF, is a type of cyberattack that causes a logged-on victim’s browser to send a forged HTTP request, and uses the victim’s session cookie and other automatically included authentication information to a vulnerable web application.

Attackers use cross-site request forgery as a means to trick their targets into unwanted actions, such as changing a password, deleting an address, or altering a username. They can even use CSRF attacks to trick people into purchasing a product or sending money to another bank account. In other words, this type of vulnerability is particularly dangerous because it triggers a browser action without the user’s knowledge. It also makes life difficult for security teams, because malicious requests can appear similar to genuine requests.

Cross-site request forgery vulnerabilities have been around since 2001, and they continue to be a problem to this day. That’s why it’s essential to understand how CSRF attacks work, how to mitigate cross-site request forgery, and what you can do to prevent this type of vulnerability.

How does cross-site request forgery work? 

Cross-site request forgery attacks work by allowing the attacker to force a victim’s logged-in browser to generate requests that the vulnerable application thinks are legitimate requests.

For example, let’s say you are logged in to your YouTube account, and an attacker wants to leverage that logged-in status to change your password. They could write a malicious POST or GET request into a link that, when clicked, sends the malicious request to YouTube. Because you are already logged-in, YouTube thinks the request is valid and the attacker is allowed to change your account password.

Here’s a very simplified example of what a malicious CSRF request might look like:

GET https://exampleplatform.com/password.do?change_to=123456

The attacker could then place this code within a link, which they send via email or chat. If you click the link, then the password is changed to one that the attacker knows.

How to mitigate cross-site request forgery attacks

Similar to other vulnerabilities like buffer overflow and cross-site scripting, CSRF attacks can be mitigated by adherence to best practices in conjunction with security testing. Here are a couple of best practices to help users remain less vulnerable to CSRF attacks:

1. Always log out of accounts when finished. We know, we know—it’s faster to simply close the window of the account you’re working in rather than signing out (especially when sites make it difficult to find the log out, too). Since CSRF attacks depend on session cookies of logged-in users, this step can really make a difference.

Secure usernames and passwords. The best way to safeguard this type of log-in information is to use a password manager program. This way, you don’t end up using the same credentials for multiple accounts.

Beyond these best practices, you can also generate unique, random CSRF tokens on the server-side for individual user sessions. Essentially, the token is checked and verified by the server. The session is rejected if duplicate tokens, missing values, or a mismatch between the session ID and token is identified. While not foolproof, this approach helps mitigate CSRF attacks because without the tokens, attackers cannot establish legitimate requests with the backend servers. 

How to prevent CSRF attacks

Developers can help prevent attacks like cross-site request forgery by:

• Using anti-CSRF tokens. These tokens are unique, unpredictable, and tied to the user’s session. They are included in forms or as custom HTTP headers and verified by the server before processing any request.
• Setting the SameSite attribute of cookies to Strict or Lax can help prevent CSRF attacks by ensuring that cookies are only sent with requests originating from the same site. Strict is the most secure option, but it may break some functionality if not implemented carefully.
• Applying additional authentication for sensitive actions. Requiring users to re-authenticate for critical actions, such as changing passwords, adds an extra layer of security against CSRF attacks.
• Referer-based CSRF defenses. Used to verify that the request originated from the application’s own domain. This approach is generally less effective and is often subject to bypasses.

It also helps to monitor traffic or work with a cybersecurity provider that offers Managed Detection and Response (MDR) Services. MDR teams can prevent, detect, and respond to attacks like CSRF, as well as monitor for suspicious traffic and analyze logs to respond quickly to potential attacks.