Table of Contents
Is Csrf Attacks Dead

Cross-Site Request Forgery (CSRF), once prominent in the OWASP Top 10, was omitted from the 2017 version due to improved browser defenses and widespread adoption of CSRF safeguards in various frameworks.

In this blog, we’ll explore what is a CSRF attack. How do CSRF attacks exploit user trust to compromise web applications? understanding their mechanisms and the strategies to thwart them. Furthermore, we’ll unravel the layers of SameSite cookies—a cornerstone in modern browser security—examining their transformation from an optional safeguard to an industry standard. Whether you’re a seasoned developer, an aspiring cybersecurity enthusiast, or simply intrigued by the ever-evolving landscape of online protection, this blog is your gateway to a safer and more secure web experience.

What is a CSRF Attack?

In a Cross-Site Request Forgery (CSRF) exploit, attackers, deceive users into submitting unauthorized requests within an active authenticated session. These attackers can directly phish victims or inject malicious content into web applications, subsequently loaded by unsuspecting users. In either scenario, the CSRF payload manipulates the victim’s browser, compelling it to execute a request in the context of the web application, including its session cookies. The most concerning aspect of CSRF vulnerabilities lies in their potential to allow any visited site to issue requests, provided the user is authenticated and the browser forwards cookies to the target application. Attackers could focus on phishing a particular user, launching a subsequent CSRF attack, or compromise a website to launch widespread CSRF attacks on visitors. Alternatively, users might unintentionally stumble upon malicious sites while browsing.

How do CSRF Attacks Exploit User Trust to Compromise Web Applications?

Let’s try to understand this with an example.

Imagine you are sitting in a coffee shop and you are logged into your bank portal, say ‘’ to check your expenditure. While you are busy with your work, an attacker notices you are logged in to the website. He somehow gets to know your name and eventually finds out your email address through, let’s say, your social media profiles. He then crafts an email posing as your personal account manager from, expressing gratitude for your banking services and enclosing a link that promises a gift coupon as an acknowledgment.

In the midst of your busy routine, curiosity piqued, you click on the link within the same browser.  Now, since you are already logged into, the browser believes this request is originated by you and hence sends your session token as a part of the request. Unknown to you, this triggers an unintended transaction from your account to the attacker’s account.

The attacker manipulated your browser’s automatic behavior to send the session cookie as a part of all the requests from the target site (‘’ in our case) in case you are already logged in to the website to perform actions on your behalf without your consent.

The nature of a CSRF vulnerability’s impact hinges on the targeted web application. Scenarios range from unauthorized money transfers in banking apps to creating new users, potentially with administrative privileges, or manipulating passwords to facilitate account takeovers.

However, the dynamics of browser behavior are evolving, as we’ll discuss later. Without proper CSRF countermeasures, the web application struggles to distinguish legitimate from malevolent requests, leading to the execution of the latter within the victim’s session.

What are SameSite Cookies?

A SameSite cookie is a security feature used in web browsing to control how cookies are shared between different websites. It prevents cookies from being sent with cross-site requests, enhancing user privacy and security. This attribute can be set to “Strict” (cookies only sent within the same site), “Lax” (cookies sent with top-level navigations), or “None” (cookies sent with cross-site requests, but requires HTTPS and Secure attribute). We will talk about it in detail later in the post.

CSRF Token

Until the adoption of SameSite cookies, web applications remained vulnerable to CSRF unless explicit mitigation was employed. Unlike coding flaws that lead to vulnerabilities, CSRF exploits leverage inherent browser and web application behaviors. Consequently, the responsibility falls on applications to rectify this vulnerability.

To counter CSRF attacks, applications can demand users to furnish exclusive proof of initiation for requests. A mere cookie won’t suffice, given that browsers automatically transmit cookies to their originating domains. A widely adopted strategy involves embedding a token or nonce—often termed a CSRF token—within a concealed input field. This token is unique for each page or session and specific to individual users created by the application. The web application subsequently validates incoming requests based on this CSRF token. Absence or invalidity of the token warrants rejection of the request. This approach mandates the application to manage user-token associations.

SameSite Cookie Enhancement

Though initially introduced in 2016 and first embraced by Google Chrome, the SameSite attribute now garners support across major browsers. This attribute instructs browsers on handling cookies during cross-site requests, a scenario where one site initiates requests to another.

Three valid SameSite attribute settings exist. The first, “None,” prompts the browser to dispatch the cookie with any relevant request, regardless of origin. However, some browsers block such cookies if the Secure flag isn’t set.

Set-Cookie: session= E6hRwN9jTcP7gF1LmZxY; SameSite=None; Secure

The second setting, “Lax,” bars the browser from transmitting the cookie during cross-site POST requests. Yet, the browser includes the cookie during manual URL input or when users click links leading to the site. Similarly, the cookie is omitted in background requests, such as those triggered by scripts, iframes, or references to resources like images.

Set-Cookie: session= E6hRwN9jTcP7gF1LmZxY; SameSite=Lax 

The third setting, “Strict,” mandates the browser to share the cookie only if the requesting domain aligns with the cookie’s domain. In contrast to “Lax,” Strict cookies aren’t sent when users navigate via links from external domains.

Set-Cookie: session= E6hRwN9jTcP7gF1LmZxY; SameSite=Strict 

Upon the initial introduction of SameSite, there was reluctance to establish it as the default behaviour. Concerns surrounding possible disturbances, modifications to expected (legacy) functions, and the overarching fear of hindering progress acted as inhibitors. As a result, SameSite was initially implemented as an opt-in feature. However, this approach is undergoing a transformation.

Should a web application neglect to specify the SameSite flag for a cookie, browsers independently determine handling. Google Chrome, for instance, defaults to treating cookies without a valid SameSite attribute as SameSite=Lax from 2021 onwards.

As mentioned above, websites possess the option to exclude themselves from SameSite protections should they deem it necessary or preferable. This exclusion can be facilitated by designating SameSite=None for their cookies. Chrome acknowledges and honours this preference, provided that the cookie must be accompanied by the Secure flag.


In conclusion, enhancing security defaults, such as SameSite attribute adoption, presents a proactive approach. While site operators can opt out if needed, the industry benefits from widespread default usage, fostering a safer web landscape.

Does this stop the CSRF attack forever? Certainly not. CSRF attacks are not extinct, despite advancements in security. They have become less prevalent due to improved awareness and preventive measures within web development. However, websites lacking proper security implementations can still be vulnerable. It’s crucial to acknowledge that CSRF attacks remain a potential threat, emphasizing the need to stay informed, apply security practices, and implement safeguards to mitigate their risks effectively.

I hope this article helped in understanding what is a CSRF attack, How do CSRF attacks exploit user trust to compromise web applications, and more about SameSite cookies and their evolution.

Aroma Rose Reji

Aroma is a cybersecurity professional with more than four years of experience in the industry. She has a strong background in detecting and defending cyber-attacks and possesses multiple global certifications like eCTHPv2, CEH, and CTIA. She is a pet lover and, in her free time, enjoys spending time with her cat, cooking, and traveling. You can connect with her on LinkedIn.

Recently added

Application Security

View All

Learn More About Cyber Security Security & Technology

“Knowledge Arsenal: Empowering Your Security Journey through Continuous Learning”

Cybersecurity All-in-One For Dummies - 1st Edition

"Cybersecurity All-in-One For Dummies" offers a comprehensive guide to securing personal and business digital assets from cyber threats, with actionable insights from industry experts.



View All

Learn Something New with Free Email subscription