Sign Up Login
Resource Center  >  Blog

CSRF Attacks: Real Life Attacks and Code Walkthrough

February 17, 2021
Admir Dizdar

What is CSRF Attack?

Cross-Site Request Forgery (CSRF) attacks execute unauthorized actions on web applications, via an authenticated end-user’s connection. Threat actors typically use social engineering schemes to trick users into executing these attacks. 

For example, a user might receive an email or a text message with a link, which deploys malware or injects malicious code into a web page. Once the user clicks the link, attackers use the malware or injected code to send requests to the web application on the user’s behalf.

A CSRF attack is limited to the permissions of the targeted end user. An end user with limited permissions can be forced into changing email addresses, or transferring funds, while an admin account can be forced to compromise an entire web application.

This article focuses on the anatomy of CSRF attacks. To learn more, including how to prevent attacks, see our complete guide to CSRF.

In this article, you will learn:

  • Real World CSRF Attack Examples
  • How Does a CSRF Attack Work?
  • Cross-Site Request Forgery Attack Code Example

Real World CSRF Attack Examples

The first CSRF vulnerabilities were reported in 2001. Because CSRF is carried out from the attacker’s IP address, it often leaves no forensic evidence in a website’s logs. For this reason there are a few reported incidents of CSRF, although the real number of attacks is much larger.

Here are a few examples of notable CSRF attacks.

  • TikTok—in 2020, ByteDance received reports of a vulnerability that allowed attackers to send messages containing malware to Tiktok users. After deployment of the malware, the attackers could perform CSRF or cross-site scripting (XSS) attacks, causing other user accounts to submit requests on their behalf to the TikTok application. TikTok patched the vulnerability within three weeks.
  • McAfee—in 2014, Check Point researchers discovered a CSRF vulnerability in the User Management module of an enterprise security product, McAfee Network Security Manager. The attack allowed malicious users to modify other user accounts. The vulnerability was patched in version
  • YouTube—in 2008, Princeton researchers discovered a CSRF vulnerability on YouTube, which allowed attackers to perform nearly all actions on behalf of any user—including adding videos to favorites, modify friend/family lists, send messages to a user’s contacts, and flagging inappropriate content. The vulnerability was immediately fixed.
  • ING Direct—in 2008, ING Direct, the banking website of a Dutch-owned multinational banking group, had a CSRF vulnerability that allowed attackers to transfer money from users’ accounts, even though users were authenticated with SSL. The website did not have any protection against CSRF attacks, and the process of transferring funds was easy for attackers to see and replicate. 

How Does a CSRF Attack Work?

Browsers can automatically cache or store user website credentials, including information about session cookies, IP addresses, basic authentication credentials, and more. The purpose of this mechanism is to allow users to continuously access web applications without having to authenticate at every step. 

Once a user is authenticated, a website vulnerable to CSRF cannot distinguish between a legitimate user request and a forged one.

Most CSRF attacks trick users into clicking a malicious link. The link is often delivered via emails and chat messages using social engineering techniques. 

The link may include malicious JavaScript or HTML code, which contains a request. Once a user clicks on the link, the code requests a specific task. If the attack is successful, the browser executes the task, letting the attacker perform unauthorized actions using the user’s session. 

In addition to tricking users, threat actors can also directly store CSRF flaws on a vulnerable site. This is a much larger risk because it allows the attacker to control multiple user sessions, including administrator accounts, without having to trick each user into performing an action. 

Attackers create CSRF attacks by either storing IFRAME or IMG tags in HTML fields or by launching cross-site scripting (XSS) attacks. 

Cross-Site Request Forgery Attacks Code Example

To illustrate a CSRF attack, take an eCommerce website,, that uses GET requests to accept purchases from customers. We’ll show how attackers can use CSRF to purchase products using other user’s accounts.

1. Attacker observes URL request format

The attacker observes that purchase requests on the website are in this format. 


The request assumes that the user has an open session with the website. It uses an address ID to reference an address defined by the legitimate user.

2. Attacker crafts a forged request URL

The attacker now creates a forged URL that will purchase a product with a high purchase price, using another user’s account.


The attacker manipulates three parameters in the request—changing the product to a product they want to buy, changing the amount, and using their own address.

3. Attacker hides the URL in an image

There are a number of ways to get the user to load the forged request URL. A common tactic is to hide the URL in an image tag, and embed it in an email sent to the victim, or a website they will visit. The image tag would look like this:

<img src  = “” width=“0” height= “0”>

4. Attacker uses social engineering to get the user to load the image

The attacker sends a phishing email to the victim, which either directly includes the image, or includes a link to a web page that embeds the malicious image tag. The URL is loaded on the user’s device.

5. Ecommerce site receives the forged request

Assuming that the user has an active session with the ecommerce site, when the URL is loaded, the website receives the forged purchase request. The website cannot identify that the request was not made directly by the legitimate user. It obeys the request and sends the goods to the attacker, billing the legitimate user’s account. 

To learn how to prevent CSRF attacks, see our complete guide to CSRF

Preventing CSRF Attacks with Bright

Bright helps 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 appear in production. Bright completes scans in minutes and achieves zero false positives, by automatically validating every vulnerability. This allows developers to adopt the solution and use it throughout the development lifecycle. 

Scan any web app, or REST, SOAP and GraphQL APIs to prevent CSRF vulnerabilities – try Bright free.

Related Articles:

Related topics

Dynamic Application Security Testing (DAST) is a crucial component in fortifying web applications against potential vulnerabilities. By taking a proactive stance, DAST systematically detects and addresses security flaws.

See more

By mapping Dynamic Application Security Testing (DAST) to the Payment Card Industry Data Security Standard (PCI DSS) requirements, organizations can

See more

What Is Mobile Application Security Testing?  Mobile application security testing is the process of assessing, analyzing, and evaluating the security

See more

Test Your Web App for 10,000+ Attacks

See Our Dynamic Application Security Testing (DAST) in Action

  • Find & fix vulnerabilities fast
  • Zero false positives
  • Developer friendly

and see how easy AppSec can be

Prevent CSRF Attacks. Run a security scan with every build

  • Easily and quickly find & fix security bugs

  • Automate it in your build pipeline

  • No false positives

  • Scan any target: web apps & APIs

Test Your Web App for 10,000+ Attacks

Integrate vulnerability testing into your DevOps pipeline. Find & fix vulnerabilities fast with zero false positives.
See Our Dynamic Application Security Testing (DAST) in Action
Testing variance Using Legacy Dast Using Dev-Centric Dast
% of orgs knowingly pushing vulnerable apps & APIs to prod 86% 50%
Time to remediate >Med vulns in prod 280 days <150 days
% of > Med vulns detected in CI, or earlier <5% ~55%
Dev time spent remediating vulns - Up to 60x faster
Happiness level of Engineering & AppSec teams - Significantly improved
Average cost of Data Breach (US) $7.86M $7.86M