What Is Cross Site Request Forgery? The 5-Minute CSRF Guide for Business Owners

Cross site request forgery (CSRF) is when an attacker makes a browser perform unauthorized actions. 

Simple enough. 

Does it matter if you’re running a business? Absolutely. Daily, attackers are using every trick in the book to get past your defenses. And one of those ways is cross site request forgery. 

It tricks customers logged into your app into doing the attacker’s dirty work for them. 

And the worst part is your web application can’t tell the difference between a real request from your customer and a fake one from the attacker. 

What is CSRF (cross site request forgery)? 

Here’s the no frills answer: Cross site request forgery is a web security attack that exploits the trust your app has in authenticated users. It’s the opposite of cross site scripting (XSS). 

Cross site scripting (XSS) vs cross site request forgery (CSRF): What’s the difference? 

While XSS exploits the trust users have in your site, CSRF exploits the trust YOUR SITE has in the user’s browser.  

Why should you care about cross site request forgery? 

Because it can have a massive impact on whether your business survives. 

Now, let’s talk about cookies (the digital kind). 

Your web application relies on cookies to identify who’s making requests. 

When someone logs in, you give them a cookie. And their browser automatically includes that cookie with every request they make to your site. 

This means they don’t have to re-enter their credentials every five seconds. 

But here’s the problem: Browsers automatically include ALL matching session cookies with same-site requests to your app. 

And requests from a malicious site can also include them, if cookies aren’t configured properly in your app. 

So, when an attacker tricks your authenticated customer into submitting a forged request, your app thinks, “Hey, this request has valid session cookies. Must be legit!” 

Your app then processes the request without question. 

This can include changing passwords, modifying data, deleting info, transferring funds, or making purchases.  

What can happen if your customers experience a cross-site request forgery attack? 

If the attacker targets user accounts, you’ll have unhappy customers calling. Which means dealing with chargebacks, fraud claims, and accusations that your site isn’t safe. 

The financial impact

• Chargeback fees add up as you make refunds 

• Refunds cut into your revenues 

• Legal fees accumulate when customers lawyer up 

The regulatory impact

• Breach notifications put your failure in writing 

• Compliance fines drain your budget 

• State AG investigations tie up your legal team 

• FTC scrutiny leads to mandatory audits and civil penalties 

The brand impact

• Negative reviews multiply on social media 

• Banks avoid your business 

• Existing customers abandon your brand 

• New customer acquisition stalls 

The brutal truth: One successful CSRF attack against your customers can leave your business gasping for air. 

Now let’s see how a real attack works. Because every step is what can happen to your business if you don’t have the right protections in place. 

How does cross site request forgery (CSRF) work? 

Now I know what you’re thinking: I’ll just hire someone to handle the technical stuff. 

Which is perfectly reasonable.  

However, it’s easier to protect what you understand.  

By knowing how CSRF works, you can ask your developer the right questions. And you can make better decisions on how to invest your security budget. 

Without further ado, here’s how a CSRF attack goes down: 

Step 1: The attacker creates a forged request

First, attackers identify state-changing actions on your site, i.e. operations that modify data, change settings, or transfer money. These are the targets.  

They then create a forged request that, when executed, performs the action they want, like transferring $20,000 to their account. 

Step 2: The attacker embeds the poison

Now, they need to get your customers to trigger that request. How? 

They embed the forged requests into: 

• Hyperlinks in bulk phishing emails 

• Invisible image tags on compromised sites your customers visit 

• Hidden forms that auto-submit when the page loads 

• Fake buttons or download prompts on social media disguised as “free offers,” coupons, or games 

Step 3: Your customer triggers the attack unknowingly

Your customer clicks the email link or button offering a big discount for the newest iPhone or Android. 

Or they visit what looks like a funny video link on social media. 

What they’re doing, unknowingly, is triggering a payload. 

Their browser, still logged into your site, automatically sends the malicious request for the transfer. 

And the request is sent with your customer’s valid session cookies. 

Step 4: Your server processes the request as legitimate

Your app sees the request and sees the valid session cookies. 

It processes the transaction. 

And just like that, $20,000 has been withdrawn from your customer’s account. 

Conditions that make the above CSRF attack successful

• Sessions authenticated via cookies only: Your app makes the dangerous assumption that any request with valid session cookies is legitimate. 

• No secondary verification: Your app identifies users solely via session cookies. There’s no explicit user intent verification, no origin checks, and no stepped-up verification for sensitive operations. 

• Human factors add to the mix: Users remain signed in across tabs and sessions, due to force of habit and convenience. 

When all three conditions exist, they make CSRF attacks more likely to happen. 

What is an example of CSRF? The real-world reality you’re up against

Palo Alto describes how Ubiquiti, a networking hardware vendor, faced a CSRF vulnerability in its router configuration interface: 

• A user logged into their Ubiquiti router admin panel... 

• Visited a malicious site... 

• The site sent a forged request to the router’s admin interface... 

• The router accepted the request because the user was still logged in to the router's admin panel. 

Here’s where it gets worse for newer apps. 

Many businesses think they’re safe because they use modern JSON APIs, but attackers have adapted. They can: 

• Craft requests that target JSON-based endpoints 

• Attack mobile apps that lack explicit CSRF protections 

• Chain CSRF with other threats like XSS to amplify damage 

Modern CSRF attacks are now targeting cloud providers, DevOps platforms, and SaaS apps (with a focus on patient portals). 

So, what actually stops modern CSRF? 

How to prevent CSRF: The 5-minute conversation to have with your dev team 

If you have developers on your team, they likely already have these CSRF protections in place. For peace of mind, ask your dev team to walk you through them: 

Technical controls

#1 Require CSRF tokens (synchronizer token pattern)

• Does every state-changing request include a unique, unpredictable CSRF token? 

• Are tokens tied to individual user sessions? 

• Are tokens validated server-side for every sensitive request? 

Synchronizer tokens provide the most reliable defense. 

#2 Enforce the right SameSite cookie settings

Even though modern browsers now default to Lax, are cookies configured properly? 

• Default to SameSite = Strict for admin sessions and internal apps. This setting means browsers won’t send cookies for cross-site requests. 

• SameSite = Lax for most public-facing apps. Cookies are sent for top-level navigation (e.g. clicking a link) but not for background cross site requests (hidden forms, iframes) 

• SameSite = None only when cross-site behavior is required. Must be paired with Secure 

Also: Have we tested to ensure our SameSite cookie settings don’t break legitimate login flows in mobile WebViews and with SSO/OAuth? 

#3 Don’t allow state-changing GET requests

For state-changing actions (modifying account settings, changing passwords, making financial transactions), what do we use to ensure requests can’t be forged from another site? 

OWASP recommendation: All state-changing actions should use POST, PUT, PATCH, or DELETE combined with CSRF tokens. 

#4 Reject requests without valid Origin or Referer headers

Are we accepting requests only when Origin and Referer headers match our domain, or are we checking that requests originate from our domain? 

#5 Ensure framework-level CSRF defenses are in place

If we’re using Django, Rails, Laravel, AngularJS, or another framework (tools used to build websites and apps), are the built-in CSRF defenses enabled and properly configured? 

#6 Protect API endpoints that don’t maintain session state

Can you walk me through how we’re protecting our APIs from CSRF? 

Architecture and identity controls 

#1 Enforce MFA, SSO, and LastPass SaaS Monitoring

• Are we enforcing MFA/SSO to prove employees logging in are authorized? 

• Do we have tools like LastPass SaaS Monitoring to verify who’s accessing our systems? Try LastPass SaaS Monitoring for free with a Business Max trial (no credit card required). 

#2 Implement rate limiting and anomaly detection for sensitive endpoints

If a user initiates an action that breaks their normal patterns (rapid-fire requests, unexpected IPs), are we requiring reauthentication or additional verification? 

#3 Leverage modern authentication flows when possible

• Are we using JWTs (JSON web tokens) for stateless authentication? 

• Are we using OAuth 2.0 to define token issuance flows from IdPs? 

• Are we rotating and expiring tokens aggressively? 

All the above, combined with employee awareness training, provides a layered defense against CSRF. 

If you feel intimidated, remember: Your dev team already knows about CSRF, so just ask: What’s your assessment of the risks? Where do you feel we’re already strong, or can you walk me through the protections in place? 

If your budget is tight, remember that perfect security isn’t possible, but every defense you add makes the next one easier – and your business more resilient. 

Sources 

OWASP: Cross site request forgery

OWASP: Cross site request forgery prevention cheat sheet

Port Swigger: Cross site request forgery

Cloudflare: What is cross site request forgery?

Ghost Security: CSRF in 2025: Not dead, just different

Geeks for Geeks: What is cross site request forgery?

Cookie Script: SameSite cookie attribute explained

Palo Alto Networks: What is cross site request forgery?

Mold Stud research team: The impact of poor security practices - Real-world examples of CSRF attacks

Web.Dev SameSite cookies explained

Web.Dev SameSite cookie recipes