What Is a CSRF Attack? How Hackers Abuse Your Login Session
CSRF means Cross-Site Request Forgery.
The attacker does not need your password. They need your browser to already be logged in — then they trick that browser into sending a request you never meant to send.
Quick takeaway: Your cookies authenticate the request. If the site cannot tell “you clicked this” from “a hidden form on evil.com clicked this,” CSRF is possible.
A story version
You are logged into your bank tab.
You open a malicious page in another tab.
That page auto-submits a transfer request to the bank.
Your browser attaches the bank cookies automatically.
Unless the bank checks a CSRF token (or similar defense), the transfer may succeed.
What hunters look for
State-changing actions without strong anti-forgery controls:
- Change email / password
- Add payees
- Create API tokens
- Connect OAuth apps
- Disable 2FA
Why SameSite cookies matter (but are not the whole story)
Modern browsers send fewer cross-site cookies by default. That reduced classic CSRF a lot.
CSRF still appears when:
- Cookies are
SameSite=Nonefor cross-site needs - The “cross-site” boundary is weaker than people assume
- XSS exists on a related origin (different bug class, similar end result)
- Older browsers or special clients are in scope
How to prove CSRF cleanly
- Capture a state-changing request while logged in
- Rebuild it as a minimal HTML form on an external origin (in labs / allowed tests)
- Show the action succeeds without the user knowingly submitting the real UI
- Confirm whether a CSRF token, custom header, or SameSite setting blocks it
Fixes to recommend
- Anti-CSRF tokens on state-changing requests
SameSitecookie attributes where appropriate- Prefer non-simple requests that require custom headers for APIs
- Re-auth for highly sensitive actions
Original Bugflare article. Concepts aligned with PortSwigger CSRF academy material. Test only where authorized.