What Is Cross-Site Request Forgery? How CSRF Attacks Work

If you run a web app with logins, someone will eventually ask what is cross-site request forgery and whether your app is exposed to it. The short answer: it is an attack that gets a logged-in user's own browser to send a request the user never meant to send, to a site that trusts that browser. whitehatstoic is a software, security and AI safety practice. Cross-site request forgery is a web app weak spot that is easy to miss, because it hides in ordinary forms and settings pages that nobody thinks of as risky.

What Is Cross-Site Request Forgery?

Cross-site request forgery, usually shortened to CSRF, is an attack where a page on one site causes the victim's browser to send a state-changing request to another site where the victim is already signed in. The target site sees a valid session cookie and treats the request as a real action by the user.

The attacker never steals the password or the cookie. They do not need to. They only need the victim's browser to carry the request, because the browser adds the credentials on its own.

The CSRF entry on Wikipedia calls this an example of a confused deputy problem: a program with authority (here, the browser holding a session) is tricked by a party without authority into using that authority on the attacker's behalf. The server cannot tell the difference, because the request carries every credential it checks.

How a Cross-Site Request Forgery Attack Works Step by Step

Take a concrete case. A user manages an online store at shop.example. The settings page has a form that changes the account email, and it sends a POST to /account/email with one field, new_email. Here is how an attacker abuses it.

1. The user signs in to shop.example. The server sets a session cookie in the browser.
2. Later, with that session still active, the user opens a link in another tab. It leads to a page the attacker controls.
3. That page holds a hidden HTML form whose action is https://shop.example/account/email, with new_email set to an address the attacker owns.
4. A line of script on the page submits the form as soon as it loads. The user sees nothing, or a blank frame.
5. The browser sends the POST to shop.example and attaches the session cookie, because the cookie belongs to that domain.
6. The server checks the cookie, finds a valid session, and changes the email.
7. The attacker requests a password reset, receives the link at the new address, and takes over the account.

Notice what the attacker needed: the URL of the endpoint, the names of its fields, and a way to get the user to load one page. Everything else came from the browser.

Why Browsers Attach Cookies to Forged CSRF Requests

An HTTP cookie is tied to the site that set it. For most of the web's history, browsers sent a site's cookies on every request to that site, no matter which page started the request. A form on attacker.example posting to shop.example got shop.example's cookies.

The same-origin policy does protect something here, but not the thing people often expect. It stops the attacker's page from reading the response from shop.example. It does not stop the request from being sent. For a CSRF attack, sending is enough, since the damage happens on the server the moment the request is processed.

Common CSRF Targets in Web Apps and AI Tool Dashboards

Any action that changes state and relies only on a cookie for identity is a candidate. The ones that matter most are actions an attacker can turn into further access.

• Account recovery settings. Changing the email or phone number, or setting a new password without asking for the current one.
• Money and orders. Transfers, refunds, shipping address changes, saved payment methods.
• Admin actions. Inviting a user, changing someone's role, turning off two-factor login for the account.
• GET requests that change things. A link such as /posts/42/delete can be triggered by an image tag, with no form at all.

Dashboards for AI tools add new targets of their own. An attacker who can forge requests to an AI product's settings page may be able to point a webhook at their own server so conversation data gets sent there, add a connector that gives an agent access to the attacker's documents, edit the system instructions for a shared assistant, or turn on a tool permission that lets a model send email or run code.

How to Prevent Cross-Site Request Forgery With Tokens, SameSite Cookies and Origin Checks

Good defense uses more than one layer. Each covers gaps in the others.

Anti-CSRF tokens

The server creates a random, unpredictable token tied to the session and puts it in every form as a hidden field, or exposes it to the app's own JavaScript for use in a header. On every state-changing request, the server checks that the token is present and matches. The attacker's page cannot read the token, because the same-origin policy blocks it from reading pages on the target site, so it cannot build a valid request. Most web frameworks ship this protection; the usual failure is a route where someone switched it off.

SameSite cookies

Google Chrome 51 brought in the SameSite cookie attribute in 2016, with the values Strict, Lax and None. It tells the browser when to send a cookie on requests that start from another site. SameSite=Strict never sends it cross-site. SameSite=Lax sends it only on top-level navigations that use safe methods such as GET, which blocks the hidden POST form in the earlier example. SameSite=None sends it everywhere. Set session cookies to Lax or Strict explicitly instead of relying on a browser's default.

Origin checks

Browsers send an Origin header with cross-site POST requests. The server can refuse any request that changes state when that header names a site other than its own. It is a short piece of middleware, and it is a second layer behind the token, not a replacement for it.

Habits that close the remaining gaps

• Never change state on GET.
• Ask for the current password, or a fresh second factor, before changing email, password or recovery options.
• Reject request bodies whose Content-Type does not match what the endpoint expects.
• Go over every route that changes data and confirm it sits behind the token check, especially routes added after launch.

How CSRF Differs From Cross-Site Scripting and Prompt Injection

CSRF is often confused with cross-site scripting, but the two work from different places. In CSRF the attacker stays outside the target site and borrows the browser's credentials. In XSS the attacker gets script to run inside the target site's own origin. That difference matters for defense: script running inside the origin can read the anti-CSRF token and send any request it wants, so an XSS bug defeats CSRF protection entirely. A walkthrough of the three kinds of cross-site scripting and how to stop them covers that side.

Prompt injection shares CSRF's shape more than its mechanics. A language model reads text from a web page, email or file, and hidden instructions in that text get the model to take actions with the user's permissions. The model plays the same confused deputy role the browser plays in CSRF: it holds authority, and an outside party steers how it is used. The defenses differ, since there is no token a model can check, and the ways to stop an LLM app from following hidden instructions rely on limiting what the model is allowed to do and confirming risky actions with the person.

Frequently asked questions

Is CSRF still a risk with SameSite cookies?

Yes, though a smaller one. Lax still sends cookies on GET requests from other sites, so any GET that changes data stays open, and a cookie set to SameSite=None gets no protection at all. Tokens or origin checks are still needed.

Can a CSRF attack read data from the target site?

Not directly. The same-origin policy stops the attacker's page from reading the response, so CSRF changes data rather than reading it, but a forged change such as a new webhook or recovery email can lead to data being sent to the attacker later.

Do APIs that use bearer tokens need CSRF protection?

If the token travels in an Authorization header set by the app's own code, the browser does not add it automatically, so classic CSRF does not apply. If the same API also accepts a session cookie, it needs CSRF protection on those requests.

What is the difference between CSRF and SSRF?

CSRF tricks a user's browser into sending a request to a site. Server-side request forgery tricks the server itself into sending requests, often to internal systems the attacker cannot reach from outside.

Cross-Site Request Forgery as a Lasting Web App Weak Spot

Frameworks and browsers have made CSRF harder than it once was, yet it keeps turning up. The reasons are ordinary. A team adds a new endpoint for a mobile client and exempts it from the token check. An embedded chat widget needs SameSite=None, and the main session cookie gets the same setting by accident. A settings page for an AI agent gains a new permission toggle that nobody adds to the protected list.

Each of these is a small decision, and each reopens the hole. The same pattern shows up with SQL injection: the fix has been known for years, and the bug survives in the one place the fix was not applied. For CSRF, the reliable habit is simple to state. Every request that changes something should prove it came from the app's own pages, through a token, an origin check, or both, and every new route should be checked against that rule before it ships.