Bright Security’s Enterprise Grade Dev-Centric DAST Integrates with

Microsoft Defender for Cloud →
Product overview

See how dev-centric DAST for the enterprise secures your business.

Web attacks

Continuous security testing for web applications at high-scale.

API attacks

Safeguard your APIs no matter how often you deploy.

Business logic attacks

Future-proof your security testing with green-flow exploitation testing.

LLM attacks

Next-gen security testing for LLM & Gen AI powered applications and add-ons.

Interfaces & extensions

Security testing throughout the SDLC - in your team’s native stack.


Connecting your security stack & resolution processes seamlessly.


Getting started with Bright and implementing it in your enterprise stack.

Book a demo

We’ll show you how Bright’s DAST can secure your security posture.


Check out or insights & deep dives into the world of security testing.

Webinars & events

Upcoming & on-demand events and webinars from security experts.


Getting started with Bright and implementing it in your enterprise stack.

Case studies

Dive into DAST success stories from Bright customers.


Download whitepapers & research on hot topics in the security field.

About us

Who we are, where we came from, and our Bright vision for the future.


Bright news hot off the press.

Webinars & events

Upcoming & on-demand events and webinars from security experts.

We're hiring

Want to join the Bright team? See our open possitions.

Bug bounty

Found a security issue or vulnerability we should hear about? Let us know!

Contact us

Need some help getting started? Looking to collaborate? Talk to us.

Resources > Blog >
6 CSRF Protection Best Practices You Must Know

6 CSRF Protection Best Practices You Must Know

Oliver Moradov

What is Cross Site Request Forgery (CSRF)?

A CSRF attack can force a user to perform unwanted actions on a web application. CSRF assumes that the user is already authenticated. Attackers typically use social engineering to trick users into clicking a link that performs actions that can benefit the attacker.

For example, on an eCommerce website, the attacker can cause the user to inadvertently make a purchase. On a bank website, the attacker can cause the user to transfer funds. If the user has administrative access to a web application, CSRF can be used to compromise the entire application.

In this article:

How CSRF Attacks Work

A website consists of client-side code, typically written in HTML and JavaScript, and server-side code, which depends on the framework used to build the website. Client-side code allows users to perform actions like navigating to different URLs, submitting HTML forms, and triggering AJAX requests via JavaScript. The server-side code intercepts the data sent in the HTTP request and handles it appropriately.

These server-side actions can also be triggered by forged HTTP requests, unless you explicitly protect them. CSRF attacks occur when a malicious attacker tricks the victim into clicking on a link or executing code that triggers a forged request. The malicious code is hosted on another domain controlled by the attacker, therefore the attack is known as “cross site” request forgery.

To protect yourself from CSRF, you need to do two things. Make sure your GET requests have no side effects, and only allow non-GET requests from your client code.

csrf protection or how csrf works

6 CSRF Protection Best Practices

1. Use Same-Site Cookies

CSRF attacks are only viable because cookies are sent with any requests sent to an origin related to that cookie. You can create a flag for a cookie, which converts it into a same-site cookie. 

Threat actors can send a same-site cookie only if a user made a request from the cookie’s origin. However, it is not possible when a request is made across domains. The request source and the cookie have the same origin if the following conditions are met:

  • They have the same protocol and host, but they do not share the same IP address.
  • When applicable, they can also share the same port. 

Not all browsers support same-site cookies (see a full compatibility chart), and a same-site cookie will default to a regular cookie when a visitor uses an older browser. It means same-site cookies are more suited as an added layer of defense, and you should only use them with other CSRF security mechanisms. 

2. Use CSRF Tokens

A popular approach to stop CSRF is using a challenge token. A challenge token is connected with a specific user and is sent as a concealed value in all state-changing forms via the web application. This token is an anti-CSRF token, also known as a synchronizer token.

Here is how the anti-CSRF token works:  

  • The web server creates a token and retains it
  • The token is statically created as a concealed field of the form 
  • The user submits the form
  • The token is a part of the POST request information
  • The application compares the token created and stored by the application with the token transferred in the request
  • If these tokens are the same, the request is validated
  • If these tokens are different, the request is rejected 

This CSRF protection approach is known as the synchronizer token pattern. It secures the form from CSRF attacks because a cybercriminal also has to guess the token to trick a target into creating a valid request. Attackers cannot readily guess the token, and they cannot create it according to a predictable pattern. To improve protection, invalidate the token after a timeout period, or every time the user logs out. 

Anti-CSRF tokens are typically exposed via AJAX – they are sent as request parameters or headers alongside AJAX requests. To be successful, an anti-CSRF mechanism must be cryptographically protected. 

It is also recommended to utilize anti-CSRF options in development frameworks, rather than having developers create their own mechanisms. This reduces mistakes, makes implementation smoother, and in the end improves security. 

3. Require Stronger Authentication for Sensitive Actions

Many websites require a secondary authentication measure or need reconfirmation of login details when a user carries out a sensitive action – for example, on a password reset page. Generally, the user needs to enter their old password before they create a new password.  

This approach protects the user who could remain logged in by accident and minimizes the likelihood of CSRF attacks. 

4. Mitigate Login CSRF

CSRF vulnerabilities can occur on login forms even when users are not logged in. For example, an attacker could employ CSRF to adopt an authenticated identity of the target on an eCommerce site using the attacker’s account. If the victim then enters their credit card details, an attacker could purchase items via the target’s stored credentials. 

You can mitigate login CSRF by establishing pre-sessions that include tokens in the login form.  You can use a pre-session only before a user is verified – do not reuse it after the user is authenticated. Instead, you should destroy the session and create a new one to avoid session fixation attacks. 

If you do not trust subdomains within your master domain in your threat model, it is challenging to mitigate login CSRF. In this case, you can use strict subdomain and path level referrer header verification to mitigate CSRF on login forms.

5. Use Representational State Transfer (REST) Principles

Representational State Transfer (REST) is a set of design principles that assign actions (create, view, update, delete) to various HTTP verbs. Using REST-ful designs helps your site scale and keeps your code clean. REST demands that GET requests are only utilized for viewing resources. 

Maintaining your GET requests side-effect-free will minimize the damage that maliciously created URLs can achieve. Consequently, an attacker has to work harder to create damaging POST requests. 

6. Leverage Web Application Security Testing

After you have effectively resolved a vulnerability in a web application that could enable a CSRF attack, vulnerabilities can still occur later on. These vulnerabilities occur because developers update the application and change its code. 

Given this, it is recommended that you continually test and scan your web applications for any vulnerabilities, including those connected with CSRF attacks. You should use web applications security tools. 

CSRF Protection with Bright Security

Bright helps you automate the detection and remediation of many vulnerabilities including CSRF early in the development process, across web applications and APIs.

By shifting DAST scans left, and integrating them into the SDLC, developers and application security professionals can detect vulnerabilities early, and remediate them before they hit production. Bright completes scans in minutes and achieves zero false positives, by automatically validating every finding. This allows developers to adopt the solution and use it throughout the development lifecycle.


Domain Hijacking: How It Works and 6 Ways to Prevent It

What Is Domain Hijacking?  Domain hijacking refers to the unauthorized acquisition of a domain name by a third party, effectively taking control away from the rightful owner. This form of cyber attack can lead to significant disruptions, including loss of website functionality, email services, and potentially damaging the brand’s reputation.  Domain hijackers often exploit security

Mastering Vulnerability Management: A Comprehensive Guide

Modern day organizations face a constant barrage of cyber threats, making it imperative to implement robust vulnerability management processes. Vulnerability management is a systematic approach to identifying, evaluating, treating, and reporting on security vulnerabilities in systems and their associated software. In this blog post, we’ll delve into the four crucial steps of vulnerability management process

Vulnerability Scanners: 4 Key Features, Types, and How to Choose

A vulnerability scanner is a specialized software tool designed to assess the security of computers, networks, or applications by automatically detecting and analyzing weaknesses. These scanners proactively search for security vulnerabilities, such as unpatched software, misconfigurations, and other security gaps that could be exploited by attackers. Some scanners can simulate the actions of an attacker to help identify exploitable vulnerabilities.

Get our newsletter