What is CSRF Attack: Definition, Prevention & How It Works

You click a link in what looks like a routine email from your bank, and within seconds, $5,000 vanishes from your account, transferred to a stranger while you were simply logged in to your banking app. Many legacy web applications have vulnerabilities that make this nightmare scenario possible, and you wouldn't even know it happened until checking your balance later.

Account takeovers frequently utilize these invisible attacks, where hackers don't steal your password, they trick your browser into doing their dirty work while you're legitimately logged in. Unlike traditional hacking, you don't download malware or enter credentials on fake sites. The attack exploits something far more subtle: your browser's trust in websites you're already using.

You'll discover how these attacks actually work, why they are completely preventable with proper safeguards, and what warning signs to watch for in your own accounts. Whether you're managing a web application or simply want to protect your online banking and email, understanding this threat could save you thousands.

What is a CSRF attack?

A CSRF attack tricks you into executing unwanted actions on a web application where you're already logged in, without your knowledge or consent. Here's how it works: attackers exploit how browsers automatically include session credentials with every request to a site where you're authenticated. When you click a malicious link or visit a compromised page while logged in elsewhere, the attacker can forge requests that appear legitimate to the target application, like transferring funds from your bank account or changing your email address.

The attack succeeds because most web applications can't tell the difference between a legitimate request you intended to make and a forged one sent from a malicious site. According to security research, many legacy web applications still have CSRF vulnerabilities. The banking sector has been particularly affected, with account takeovers frequently linked to CSRF attack chains. Unlike cross-site scripting (XSS), CSRF is a "one-way" attack. Attackers can force actions but can't read the responses, which limits them to state-changing operations rather than data theft.

How does a CSRF attack work?

A CSRF attack tricks your browser into sending a request to a website where you're already logged in. The attacker crafts a malicious link or form that looks legitimate but actually executes an unwanted action using your active session credentials.

Here's the typical sequence. You log in to your bank account and leave that tab open. Later, you click a link in an email or visit a compromised website. That page contains hidden code, maybe an image tag or invisible form, that automatically sends a request to your bank. Your browser includes your authentication cookies with that request because you're still logged in. The bank's server sees valid credentials and processes the request, whether it's transferring funds or changing your email address.

The attack succeeds because three conditions align: the target action changes something important (like account settings), the application relies only on session cookies for authentication, and the request parameters are predictable enough for an attacker to forge. Many legacy web applications have CSRF vulnerabilities, primarily because they couldn't distinguish between legitimate requests you initiated and forged ones from malicious sites.

What makes CSRF particularly dangerous is that it's a one-way attack. The attacker can't see the response from your bank, but they don't need to. They've already forced the action they wanted.

What are the main types of CSRF attacks?

CSRF attacks come in several distinct forms, each exploiting different aspects of web application trust. The variants below represent the most common attack vectors security teams encounter.

• Classic CSRF: An attacker tricks you into submitting a malicious request that performs an unwanted action, like transferring funds or changing account settings. The attack works because your browser automatically includes session cookies with the forged request. Real-world examples include banking apps where victims click email links containing URLs like `https://samplebank.com/transfer?amount=5000&account=425654` while logged in.
• Login CSRF: Instead of targeting authenticated sessions, this variant forces you to log in to an attacker-controlled account without your knowledge. Once logged in, any personal data you enter, like credit card numbers or addresses, gets stored in the attacker's account. This type is a common vector for authentication bypass.
• HTML-based CSRF: Attackers inject malicious HTML elements (like image tags) into the target server via comments or forum posts. When other users view this content, their browsers automatically make the request. This effectively combines a storage vulnerability with CSRF.
• GET-based CSRF: Attackers exploit applications that incorrectly use GET requests for state-changing operations. Simple image tags like `` trigger the attack when you load a page containing the malicious code. While GET requests shouldn't modify data, many tested web applications have had this vulnerability.
• Administrative CSRF: These attacks specifically target users with elevated privileges, like system administrators or moderators. A successful attack can compromise entire applications through privilege escalation or system configuration changes. The impact multiplies because admin actions affect all users, not just the targeted account.

What are the common CSRF vulnerabilities?

Common CSRF vulnerabilities are weaknesses in web applications that fail to verify the authenticity of user requests, allowing attackers to forge malicious actions. These security gaps typically stem from missing or improperly implemented protective mechanisms. The common CSRF vulnerabilities are listed below.

• Missing CSRF tokens: Applications that don't include unpredictable validation tokens in forms and state-changing requests can't distinguish legitimate user actions from forged ones. Many web applications lack proper token use, making them easy targets for attackers who exploit this gap through malicious links or hidden forms.
• Predictable request parameters: When applications use easily guessable values for critical operations like account numbers or transfer amounts, attackers can craft forged requests without needing to steal any information. Banking apps with URLs like `transfer?amount=5000&account=425654` become vulnerable because attackers can construct these parameters through simple observation or social engineering.
• GET requests for state changes: Applications that use GET methods to modify data or perform transactions violate HTTP standards and create CSRF opportunities. Attackers can trigger these vulnerable endpoints through image tags, links, or even browser prefetching. Exploitation becomes as simple as getting you to view a malicious page.
• Inadequate SameSite cookie configuration: In older browsers, cookies without proper SameSite attributes were automatically sent with cross-site requests. While modern browsers now default to 'Lax' protection, relying on this default isn't enough for all scenarios. Legacy applications and older PHP apps often lack this browser-level protection, though modern browser adoption of SameSite policies has significantly reduced CSRF incidents.
• Insufficient origin validation: Applications that don't verify the Origin or Referer headers allow requests from any external site to trigger authenticated actions. This vulnerability becomes particularly dangerous for administrative functions, where a single forged request can compromise entire systems through privilege escalation.
• Login CSRF gaps: Authentication endpoints without CSRF protection let attackers force you to log in to attacker-controlled accounts. This variant enables data harvesting when you unknowingly enter sensitive information like credit card details into compromised accounts.
• Weak authorization checks: Applications that rely solely on session cookies without requiring explicit confirmation for sensitive operations can't detect forged requests. The banking sector reports many account takeovers involve CSRF chains that exploit this weakness to execute unauthorized transactions during active user sessions.

What are the warning signs of CSRF attacks?

Warning signs of CSRF attacks are behavioral indicators and system anomalies that suggest unauthorized actions executed through forged requests. The signs are listed below.

• Unexpected account changes: Your email address, password, or security settings change without your knowledge. These modifications often appear in account activity logs with timestamps when you weren't actively using the application. Banking apps vulnerable to CSRF allow attackers to alter contact information before attempting fund transfers.
• Unauthorized transactions: Financial transfers, purchases, or payment method updates occur while you're authenticated elsewhere on the web. Account takeovers in the banking sector are frequently linked to CSRF chains that manipulate session cookies. The transaction amounts may be small initially to avoid detection before larger transfers attempt.
• Actions performed without intent: Form submissions, profile updates, or administrative changes execute automatically when you click external links. You'll notice confirmation emails for actions you didn't initiate, like subscription changes or data exports. Login CSRF variants force authentication to attacker-controlled accounts, capturing personal data entered afterward.
• Session behavior anomalies: Multiple simultaneous sessions appear active from different locations or devices in your account security dashboard. CSRF exploits don't require stealing credentials, they piggyback on legitimate sessions. You might see API calls or state-changing requests in logs that don't match your browsing history.
• Cross-site request patterns: Browser developer tools reveal requests to your authenticated domains originating from unrelated websites you visited. Image tags or hidden forms on malicious pages trigger GET or POST requests with your session cookies attached. These forged requests lack anti-CSRF tokens that legitimate application forms include.
• Privilege escalation attempts: Administrative users notice unauthorized role changes, permission grants, or user account creations they didn't approve. CSRF targeting admins compromises entire applications when attackers trick privileged users into clicking malicious links. Research shows many web applications have exploitable CSRF vulnerabilities.

How to prevent CSRF attacks?

You prevent CSRF attacks by using multiple layers of validation that verify each request's authenticity before processing state-changing operations.

1. Use anti-CSRF tokens in every form and state-changing request. Generate a unique, unpredictable token for each user session and embed it in forms as a hidden field. When the form submits, your server validates the token matches the session value. External sites can't forge requests because they don't have access to this token. This method is highly effective when properly implemented.
2. Configure SameSite cookie attributes to Strict or Lax for all session cookies. This browser-enforced setting prevents cookies from being sent with cross-origin requests, blocking the automatic credential inclusion that CSRF attacks exploit. Chrome and Firefox adoption of this feature has significantly reduced CSRF incidents, making it one of your strongest defenses.
3. Verify the Origin and Referer headers on all incoming requests. Check that these headers match your application's domain before processing sensitive actions. If the request originates from an external site, reject it immediately. This adds a secondary validation layer that catches attempts even when other protections fail.
4. Require re-authentication for critical operations like password changes or fund transfers. Force users to enter their current password or complete two-factor authentication before executing high-risk actions. This breaks the attack chain because the attacker can't provide these credentials even if they forge the request.
5. Use custom request headers for AJAX and API calls in single-page applications. Browsers don't allow cross-origin requests to set custom headers without CORS permission, so requiring a header like X-Requested-With effectively blocks CSRF attempts. This approach has reached wide adoption in modern APIs as an alternative to traditional tokens.
6. Avoid using GET requests for any state-changing operations. GET methods should retrieve data only, never modify account settings, process payments, or alter database records. Attackers can trigger GET requests through simple image tags or links, making them particularly vulnerable to CSRF exploitation.
7. Set short session timeouts for authenticated users, especially on sensitive applications. The attack window shrinks dramatically when sessions expire after 15 to 30 minutes of inactivity. Banking applications use this approach to limit exposure, reducing successful CSRF chains by forcing re-authentication.
8. Deploy a web application firewall with CSRF-specific rulesets to monitor and block suspicious patterns. WAFs can detect anomalies like rapid form submissions or requests missing expected tokens, providing runtime protection that complements your code-level defenses.

The key thing is layering these protections. No single method provides complete coverage, but combining tokens, SameSite cookies, and origin validation creates overlapping defenses that make successful attacks extremely difficult.

How can Gcore help protect against CSRF attacks?

Gcore protects against CSRF attacks through the Web Application Firewall, which validates request authenticity across 210+ global PoPs before malicious traffic reaches your origin. The WAF can automatically add SameSite attributes to your application's cookies, validates custom headers like Origin and Referer, and blocks suspicious cross-origin requests in real time.

You'll get ML-based anomaly detection that spots unusual request patterns, like sudden spikes in state-changing POST requests from new geolocations, which signature-based tools often miss. This matters for modern SPAs where traditional token validation isn't always practical, and you need runtime protection that adapts to evolving attack techniques without breaking legitimate user flows.

Explore Gcore's application security solutions at gcore.com/waas.

Frequently asked questions

What's the difference between CSRF and XSS attacks?

CSRF tricks authenticated users into executing unwanted actions but can't read responses, while XSS injects malicious scripts that steal data directly from the victim's browser. Think of CSRF as a one-way attack that forges requests and XSS as a two-way attack that extracts information.

How much damage can a CSRF attack cause?

CSRF attacks can cause severe damage ranging from unauthorized fund transfers and account takeovers to full administrative compromise of web applications. The banking sector alone reports frequent account takeovers linked to CSRF exploits, with real-world cases showing attackers stealing thousands of dollars or capturing sensitive personal data like credit card information.

Are modern web applications still vulnerable to CSRF?

Yes, legacy apps and frameworks without built-in CSRF protections remain vulnerable, with many web applications showing CSRF flaws in security scans. Modern frameworks like Django and Rails include automatic token validation, but custom implementations and SPAs using stateless APIs can still expose gaps if developers don't enforce origin checks or SameSite cookies.

What are the requirements for using CSRF tokens?

CSRF tokens need two components: a cryptographically random value generated server-side for each session or request, and validation logic that compares the token from form submissions against the stored server value. Modern frameworks like Django and Ruby on Rails handle this automatically, but custom implementations must ensure tokens are unpredictable, tied to user sessions, and verified before processing state-changing requests.

How does HTTPS affect CSRF attack prevention?

No, HTTPS doesn't prevent CSRF attacks because encryption only protects data in transit. It doesn't verify that requests originate from legitimate sources rather than malicious sites. Browsers still automatically attach session cookies to HTTPS requests from attacker-controlled pages, allowing forged commands to reach authenticated sessions.

Can CSRF attacks be automated?

Yes, CSRF attacks can be automated using tools like Burp Suite or custom scripts that generate forged requests at scale. Attackers automate payload delivery through phishing campaigns or compromised websites, but each attack still requires the victim to be authenticated and interact with the malicious link or form.

What industries are most targeted by CSRF attacks?

Banking, e-commerce, and healthcare face the highest CSRF attack rates, with banking reporting significant numbers of account takeovers linked to CSRF chains. These industries are targeted because they handle high-value transactions and store sensitive personal data that attackers can exploit through authenticated sessions.