Home / Knowledge hub / CSRF
Knowledge hub
CSRF
An attacker's page makes a logged-in user's browser act on your site.
What it means
CSRF, or cross-site request forgery, lets an attacker's page make a logged-in user's browser perform an action on your site. Changing the email address on an account is the classic example. Your user clicks nothing on your site for it to happen.
Browsers attach your cookies to any request aimed at your domain, whoever started it. Your server sees a valid session and does as it is told. The request looks entirely normal in your logs, because in every technical sense it is normal.
Why it matters
The attacker never sees the response, and does not need to. Change an email address, request a password reset, and you have a full account takeover carried out through the victim's own browser. Adding a user or approving a payment works the same way.
Most modern frameworks now defend against this by default, which is why it turns up less often than it did. The risk moved rather than disappearing. It sits in the endpoint somebody added by hand, the integration route, the internal tool written before the current conventions. Nobody goes back to read those.
How it shows up
Any request that changes state and relies only on a cookie is exposed. OWASP recommends an unguessable token tied to the session, backed by cookies marked so browsers withhold them on cross-site requests.
The places teams still get caught are consistent. Endpoints that accept plain form submissions as well as JSON. Anything that changes state on a simple page load. Login and logout flows, which teams often exempt from the token check and should not. PortSwigger's academy has working labs for each pattern.
Questions people ask
CSRF, answered
Is CSRF still a thing, or did frameworks solve it?
It is still a thing. Frameworks cover the paths that go through them, and CWE-352 remains an active entry with a long list of real advisories behind it.
What we find in practice sits outside the framework: a route added by hand, a webhook receiver, an admin page written years ago. The default protected everything except the code that skipped the default.
Do I need CSRF protection if my API uses a bearer token?
If the token travels in an Authorization header that your JavaScript sets, then no. The browser does not attach it automatically, so another site cannot make an authenticated request.
If any part of the session lives in a cookie, then yes, even partly. Mixed setups are where this goes wrong, because one old cookie-authenticated endpoint is enough.
Do SameSite cookies make CSRF tokens unnecessary?
They help a lot and OWASP treats them as defence in depth rather than a replacement. SameSite behaviour varies by browser and by version, and Lax still permits top-level GET navigation.
Keep the token. It is the control that does not depend on what the visitor's browser decided to do this year.
Does HTTPS prevent CSRF?
No, and this is the most common misunderstanding about it. HTTPS stops somebody on the network reading or altering the request. CSRF is a request your own user's browser sends, correctly, over a properly encrypted connection.
Encryption has no opinion about who started the request. That is exactly the question CSRF exploits.
What can an attacker actually do if they cannot read the response?
Everything that matters without reading anything back. They can change an email address, add a second user, approve a transaction, disable a notification, or raise a permission.
Then they use the account they have quietly rewired. The read happens later, through the front door, as the new owner of the account.
Related
Terms that sit next to this one
Session hijacking
Stealing the token that tells your application a browser is logged in.
Account takeover
An attacker ends up signed in as one of your real users.
CORS
The browser rule for which sites may read responses from your API.
Clickjacking
Tricking someone into clicking your button while it is hidden from them.
Token
A string that stands in for an identity or a permission.
Can another site act as your user?
We test every endpoint that changes state, including the login and logout paths that often skip the token check, and hand you the request that proved it. Ask about one application.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.