Csrf Case Studies When Your Browser Lies For You

The last post ended with a promise: this course stops assuming a request came from where it claims to. Cross-site request forgery is the attack built entirely on breaking that assumption.

Not Becoming Someone. Making Someone Act.

Everything in the session hijacking chapter shared one theme: get hold of someone's session, and you get to be them. Steal the cookie, replay it, and the server can't tell the difference.

CSRF throws that whole model out.

The attacker never touches the cookie. They never see the response either, so they don't even get to confirm what they just did worked. What they get instead is a legitimate, already-logged-in browser, tricked into sending a request it never meant to send, carrying a real, valid session cookie the whole time.

Picture Neal, logged into his bank in one tab, reading a forwarded meme in another. The meme page has nothing to do with the bank. It doesn't need to. Somewhere on that page sits a hidden form, and the moment it loads, Neal's own browser submits it to the bank on his behalf, cookie and all.

Neal never typed anything. He never even looked at the hidden form. His browser did exactly what browsers are supposed to do: attach the cookie for the site the request is going to, no questions asked.

That's the whole trick. Not a stolen secret, just a legitimate mechanism, aimed somewhere the user never intended.

This Is Fire and Forget

There's one detail that separates CSRF from almost every other attack in this course: the attacker never gets a response back.

They can make the victim's browser send the request. They cannot read what comes back from it. So a CSRF attack only works for actions where the side effect itself is the payoff, not anything printed on the page afterward.

ExpandA victim's authenticated browser forced by an attacker's page to send a real request to a legitimate site, with the response never reaching the attacker.

That constraint sounds limiting. It hasn't stopped this from working, repeatedly, against companies with real security teams.

Twitter, 2010: A Worm Made of Links

In 2010, Twitter shipped an endpoint that posted a tweet from a simple GET request: twitter.com/share/update?status=.... No form, no confirmation, just a URL.

A GET request is something a browser will send from almost anywhere. A link. An image tag. A CSS background reference. Just hovering over certain links was enough to trigger one.

Someone figured out that visiting a page with the right link on it would quietly tweet that same link from your own account. Anyone who then saw your tweet and clicked it got infected the same way. That's how it became a worm: every victim's account became the next delivery vehicle, without a single stolen password anywhere in the chain.

Netflix's DVD Queue: Low Stakes, Same Bug

Netflix, back when DVDs by mail were still the product, had an endpoint like /JSON/AddToQueue that also worked over GET.

An attacker didn't need a form at all. An <img> tag pointing at that URL was enough. The browser tries to load it as an image, fails silently since the response isn't actually image data, and never renders anything. But the request still went out, cookie attached, and Netflix still added the DVD to the logged-in user's queue.

Nobody's bank account emptied out. But someone's queue silently filled up with whatever the attacker wanted them to have, and that's still someone acting on your account without your knowledge.

The New York Times: Turning "Email This" Into a Harvester

A 2008 research paper on browser security disclosed a batch of these bugs across major sites, and one of the more interesting ones targeted the New York Times.

Every article had an "email this article" form, and submitting it fired off a POST request that sent an email on the logged-in user's behalf. An attacker didn't need the article to be interesting. They needed the form to fire.

Because CSRF is fire and forget, the attacker never sees the confirmation. But they don't need to. The email itself is the leak: it reveals the victim's real email address, harvested silently, one visitor at a time, and quietly built into a spam list nobody consented to join.

That harvested list has a second life beyond spam, too. Pair a large enough batch of confirmed real email addresses with a leaked password dataset from somewhere else entirely, and the same brute-force credential-stuffing that already threatens weak passwords gets a much better target list to work from.

The Same Paper Found a Lot More

That 2008 disclosure wasn't a single bug. It described a pattern repeating across the web at the time.

• Account creation on behalf of a user, letting an attacker register accounts that traced back to someone else's session
• Fund transfers between accounts, the exact kind of action a bank should have guarded most carefully
• YouTube playlist manipulation, letting an attacker add or remove videos from someone else's playlists using nothing but a forged request

None of these needed a stolen password. They needed a logged-in browser and an endpoint that trusted the cookie without asking for anything else.

TikTok, 2020: Account Takeover Through a Third Party

CSRF didn't stay a 2008 problem. In 2020, researchers found a flow where a third-party application could trigger a password reset on TikTok through a forged request.

The reset itself was a completely legitimate feature. The bug was that nothing distinguished a reset the user actually asked for from one an attacker's page silently triggered on their behalf. Once the password changed, the attacker controlled the account, no cookie theft required at any point in the chain.

The Root Cause, Every Time

Look across all five of these and the same mistake shows up again and again: a GET request that changes something on the server.

HTTP has a basic expectation baked into it. GET is supposed to be idempotent, safe to repeat, safe to prefetch, safe to embed as an image or a background reference, because it should never alter anything. The moment a GET endpoint changes state, every one of those "safe" behaviors turns into an attack surface, because browsers, proxies, and crawlers all treat GET as something they're free to fire without asking permission first.

This Was Never a Beginner's Mistake

Twitter, Netflix, the New York Times, YouTube, TikTok. These are not small teams shipping their first web app. These are companies with dedicated security staff, and the bug still made it to production, more than once, more than a decade apart.

That's the actual takeaway here, more than any single case study. CSRF isn't a mistake careless developers make. It's a category of vulnerability that requires deliberate defense, on purpose, every time, because the browser's default behavior works against you unless you tell it otherwise.

What This Sets Up

Knowing these attacks happened is one thing. Knowing exactly what has to be true for one to work is another, and that's a much shorter list than five separate case studies makes it look.

The Essentials

1. CSRF never steals anything. It tricks an already-authenticated browser into sending a request the attacker never sees the response to.
2. A real, valid session cookie rides along automatically, because browsers attach cookies based on the destination, not on user intent.
3. The 2010 Twitter worm and the Netflix DVD queue bug both exploited GET requests that changed server state.
4. The New York Times bug turned a normal feature into a silent email-harvesting tool, one forged request at a time.
5. A 2008 research paper found the same pattern across account creation, fund transfers, and YouTube playlists. TikTok's 2020 account takeover proved this never fully went away.
6. The recurring root cause is a GET request that isn't actually safe to repeat, violating the basic HTTP expectation that GET never changes anything.

Next up: the three ingredients every CSRF attack actually needs, and why taking out just one of them is enough to stop all of this.

Further Reading and Watching

• Cross Site Request Forgery - Computerphile: a clear walkthrough of the attack mechanics behind the case studies in this post.
• Cross-Site Request Forgery (CSRF): OWASP's reference entry, including further real-world disclosures beyond the ones covered here.