Bright is now integrated with GitHub Copilot

Check it out! →
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 >
How to test for Cross-Site Request Forgery?

How to test for Cross-Site Request Forgery?

Admir Dizdar

What is Cross-Site Request Forgery Test?

Cross-Site Request Forgery (CSRF) testing is the procedure of finding and remediating CSRF vulnerabilities in web applications. A CSRF attack tricks users into submitting a malicious request. By performing a CSRF attack, the attacker inherits the identity and privileges of the victim to perform an undesired function on behalf of the victim. For most sites, the browser requests automatically include any credentials associated with the site. If the user is currently authenticated to the site, the site will have no way to distinguish between a legitimate and a forged request.

Testing for cross-site request forgery can be conducted either manually or by using automated tools. 

In this article you will learn:

What impact can a CSRF attack have?

With no protection from this attack, cross-site request forgery can expose and compromise the confidentiality and integrity of the application’s userdata. 

In many cases, a CSRF attack violates how the website handles it’s sessions. This translates to attackers being able to hijack a user’s session in order to perform actions that the user did not intend to take. As an example, an adversary can trick a user into changing their account password to a password of the attacker’s choosing, or change the shipping address to an address the attacker controls without the user’s knowledge or permission resulting in the loss of the trust of end-users. 

How does a Cross-Site Request Forgery attack work?

There are numerous ways in which an end user can be tricked into loading information from or submitting information to a web application. In order to execute an attack, we must first understand how to generate a valid malicious request for the victim to execute.

Let’s consider the following example:

A user wants to transfer $50 to a friend. The bank application is vulnerable to CSRF. The attacker wants to trick our user into transferring the money to his account instead of the friend’s account. To do that, the attacker needs to:

  • Build an exploit URL or script
  • Trick the user into executing the action with social engineering

GET Scenario

If our bank application was designed to use GET requests to transfer parameters and execute actions, the money transfer operation might be reduced to a request like:


The attacker first constructs the following exploit URL which will transfer $50,000 from the victim to the attacker’s account. The attacker manipulates the original command URL and replaces the beneficiary name and the transfer amount: HTTP/1.1

Via social engineering, by sending the victim an email with HTML content or perhaps by including the exploit URL on another page for example, the attacker can get the unassuming victim to load their URL

A real life example of CSRF attack on an application using GET was a uTorrent exploit from 2008 that was used on a mass scale to download malware.

POST Scenario

Let’s assume that our bank uses POST for transferring parameters and executing actions. The vulnerable request would look like this:


Such a request can be delivered using a form tag:

<form action="" method="POST">
<input type="hidden" name="acct" value="Filip"/>
<input type="hidden" name="amount" value="50000"/>
<input type="submit" value="View my pictures"/>

This form relies on the user clicking the submit button, but it can also be executed automatically using JavaScript:

<body onload="document.forms[0].submit()">

Other HTTP methods

APIs in modern web applications frequently use other HTTP methods, such as PUT or DELETE.

Now let’s assume that our vulnerable bank application uses PUT that takes a JSON block as an argument:


{ "acct":"Nedim", "amount":50 }

We can execute this request by using JavaScript embedded into an exploit page:

function put() {
    var x = new XMLHttpRequest();"PUT","",true);
    x.setRequestHeader("Content-Type", "application/json");
    x.send(JSON.stringify({"acct":"Nedim", "amount":50})); 
<body onload="put()">

Thanks to the same-origin policy restrictions, this request will not be executed by modern browsers. This restriction is enabled by default unless the target website explicitly opens up cross-origin requests from the attacker’s origin by using CORS with the following header:

Access-Control-Allow-Origin: *

Manual testing for Cross-Site Request Forgery vulnerabilities

If you want to discover if the session is insecure you will need to examine the application’s session. If session management is on the user side, indicating information is available to the browser, then the application is vulnerable. “Client-side values” refer to HTTP authentication credentials and cookies. 

Accessible resources via HTTP GET requests are undoubtedly vulnerable, although POST requests tend to be automated via JavaScript and are exposed and vulnerable, therefore the use of POST only is not enough to fix the occurrence of CSRF vulnerabilities.

Automated Tools for CSRF testing

1. Bright

Bright is a Dynamic Application Security Testing (DAST) scanner.  It can be integrated across the development pipelines to test your web applications and APIs, automating and simplifying the detection and remediation of CSRF and many other vulnerabilities

By shifting DAST scans left and integrating them across the CI/CD, developers and application security professionals are able to detect vulnerabilities as early as possible, to remediate them before they hit production. This allows developers to adopt the solution and use it throughout the software development lifecycle –  SDLC.

Bright’s CSRF test first checks if there is any CSRF protection implemented, by checking if the target has “Access-Control-Allow-Origin” header misconfiguration or missing “Origin” header. The second phase checks if the CSRF token itself is missing inside the request query. If all these steps are confirmed, the final step executes the requests, confirming and validating the vulnerability has been successfully exploited, to ensure there are no false positives.


OWASP ZAP is an open-source web application security scanner, used predominantly by professional penetration testers. A great tool but not developer friendly.

ZAP detects anti-CSRF tokens solely by attribute names – that is considered to be anti CSRF tokens and is configured using the Anti CSRF in options. When ZAP detects these tokens it records the token value and which URL generated the token.

3. CSRF Tester

CSRF Tester is a project by OWASP, created by a group of developers for developers, to verify the integrity of HTTP requests in their web applications. CSRF Tester provides a PHP library and an Apache Module for cautious mitigation.

4. Pinata-csrf-tool

Intended to be used by advanced application security professionals. It generates the proof of concept CSRF HTML given an HTTP request to automatically discover whether it is a GET or a POST request with further validation for standard POST and Multipart/form POST. The tool creates HTML corresponding to the type of the request.


Many tools on the market can help you discover and remediate CSRF vulnerabilities but the question is how reliable and developer friendly they are.

With Bright you can easily test for CSRF, the OWASP Top 10 vulnerabilities and many more in just a few clicks. Bright is built from the ground up to put security testing into the hands of developers, integrated seamlessly into their environment and across the CI/CD.

Bright’s automatic validation of every exploitable vulnerability it detects removes false positives and the alert fatigue that comes with it. Developers get immediate results with developer friendly remediation guidelines to prioritise and fix the security vulnerabilities before they hit production. The security team also gets an accurate snapshot of their cyber posture without the need for manual validation, removing the largest bottleneck organisations face currently.
Want to see Bright in action? Get a free account here –


IASTless IAST – The SAST to DAST Bridge

Streamline appsec with IASTless IAST. Simplify deployment, enhance accuracy, and boost your security posture by combining SAST and Bright’s DAST.

Bringing DAST security to AI-generated code

AI-generated code is basically the holy grail of developer tools of this decade. Think back to just over two years ago; every third article discussed how there weren’t enough engineers to answer demand; some companies even offered coding training for candidates wanting to make a career change. The demand for software and hardware innovation was

5 Examples of Zero Day Vulnerabilities and How to Protect Your Organization

A zero day vulnerability refers to a software security flaw that is unknown to those who should be mitigating it, including the vendor of the target software.

Get our newsletter