We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Security Architecture
Free preview: the first 2 parts of this 5-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Security Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
You are logged into your bank at bank.com. You visit a different website that contains a hidden form:
<form action="https://bank.com/transfer" method="POST">
<input type="hidden" name="to" value="attacker" />
<input type="hidden" name="amount" value="10000" />
</form>
<script>document.forms[0].submit()</script>
Your browser automatically attaches your bank.com session cookie to the request, because that is how cookies work. The bank sees a valid session, processes the transfer, and you just sent $10,000 to the attacker. You never clicked anything on bank.com. You never even saw the form.
CSRF exploits one fundamental browser behavior: cookies are attached to every request for the cookie's domain, regardless of which site initiated the request. When evil.com creates a form that POSTs to bank.com, the browser includes bank.com's cookies. The bank's server cannot distinguish between a legitimate request from its own page and a forged request from evil.com.
In 2008, a CSRF vulnerability in Netflix allowed attackers to add DVDs to victims' queues. In 2012, a CSRF in YouTube allowed attackers to perform actions on behalf of logged-in users. These attacks required no technical sophistication. A single hidden form on any website was enough.
Beginners often confuse CSRF with XSS. They are fundamentally different attacks.
CSRF forces the browser to send an authenticated request. The attacker can perform any action the victim is authorized for (transfer money, change email, delete account), but cannot read the response. The same-origin policy blocks the attacker from seeing what comes back. CSRF is a write-only attack.
XSS executes JavaScript in the victim's browser within the target site's context. The attacker can read page content, modify the DOM, steal cookies, and send data to external servers. XSS gives full read-write access to everything the legitimate JavaScript can access. It is far more powerful than CSRF.
Clickjacking loads the target site in an invisible iframe and tricks the user into clicking a hidden button. The user thinks they are clicking "Play Video" but actually click "Delete Account" on the hidden site underneath. Each click triggers exactly one action.
Each attack exploits a different browser behavior. CSRF exploits automatic cookie attachment. XSS exploits dynamic content rendering. Clickjacking exploits iframe transparency. Defending against one does nothing for the others. You need separate defenses for each.