CSRF: acting without your knowledge while you’re logged in

The principle

When you’re logged into a site, your browser automatically sends your session cookie with every request to that site — even if the request originates from a completely different page open in another tab.

CSRF (Cross-Site Request Forgery) exploits exactly that: a trap page quietly triggers an action on the site where you’re logged in, and your browser happily attaches your cookie to it. To the server, the action looks perfectly legitimate, coming from you.

A concrete example

A trap page contains an invisible form that submits itself to bank.example.com/transfer with an amount and a destination account already filled in. If you’re logged into your account in another tab when you visit that page, and the site checks nothing beyond the cookie’s presence, the transfer goes through — you clicked nothing, saw nothing.

Another common variant: an “unsubscribe” or “delete account” link sent by email, clicked out of curiosity, that fires the action immediately with no confirmation step at all.

Why it’s serious

Unlike password theft, CSRF requires NO access to your account whatsoever: it hijacks a session that’s already open — yours. Any action that changes state — changing a contact email, deleting an account, confirming an order, granting admin rights — is a potential target.

OWASP classifies this flaw under A01:2021 – Broken Access Control. On a poorly protected admin panel, a single well-aimed CSRF request can be enough to create an administrator account for the attacker.

How to protect yourself

Every form that changes data must include a unique, unpredictable anti-CSRF token, generated server-side and verified before the action executes. Without that exact token, the request is rejected, regardless of a valid cookie being present.

Complement it with the SameSite=Strict or Lax cookie attribute, which stops the browser from sending the session cookie on a request initiated from another site in the first place. The two measures reinforce each other; neither alone covers every case.

How SauronSec detects it

Every form that changes state is scrutinised: presence of a valid CSRF token, the session cookie’s SameSite attribute, the request’s origin — all checked before any conclusion is drawn.

A deliberate anti-false-positive rule: a login form containing a password field structurally doesn’t need a classic CSRF token and is never flagged for lacking one; likewise, an XSRF-TOKEN cookie readable in JavaScript by design (Angular, Django) — its missing HttpOnly IS the expected normal behaviour, not a flaw to fix.