What Is a CSRF Attack? How Cross-Site Request Forgery Works and How to Prevent It

CSRF attack is a technique that forces an authenticated user's browser to perform actions on a website without their explicit consent. For this attack, the perpetrator doesn't need to know the password, hijack the session, or get direct access to the account: it's enough that the browser already recognizes the user as logged in.

CSRF stands for Cross-Site Request Forgery. The core idea is that a malicious page or link initiates a request to another site, and the browser may automatically add authentication data like session cookies. If the server doesn't verify the origin of such requests, it might treat them as legitimate actions from the account owner.

That's why CSRF is especially dangerous for actions that change data: profile settings, email addresses, account parameters, or any other important operations. Let's explore why this attack is possible, the role of cookies, and how CSRF tokens help distinguish genuine user requests from forged ones.

What is a CSRF attack and why is it possible?

CSRF in simple terms

A CSRF attack exploits situations where a user is already authenticated on a site and the browser stores their session data. For example, after logging in to an online store or admin panel and staying signed in, the browser continues to automatically confirm requests to that site as long as the session is active.

If the user then visits a specially crafted page, clicks a malicious link, or loads an embedded element from another site, their browser might send a request to the service where they're still logged in-without the user noticing anything unusual.

The danger arises when the server only checks for an active session, but doesn't verify whether the request was initiated through the site's own interface.

In short: a user logs in, gets an active session, then visits a third-party page that triggers a request to the target service. The browser attaches authentication data, and the server treats it as if the account owner sent it.

What does Cross-Site Request Forgery mean?

The full name of CSRF-Cross-Site Request Forgery-perfectly describes the attack: a request is created on one site but sent to another as if from an already authenticated user.

It's important to distinguish between the attack and the CSRF vulnerability. A CSRF attack tries to force the browser to perform an unwanted action. A CSRF vulnerability is a flaw in a web application's logic that lets the server accept such requests without extra checks.

The browser itself isn't behaving incorrectly; it follows standard procedure, sending cookies and other domain-related data according to security settings. The problem lies on the application's side if it assumes an active session is proof that the user intended the action.

So, CSRF isn't about password theft or account hacking. The attacker uses the victim's existing authorization and tries to make the browser perform an allowed action at an inappropriate moment.

How does a CSRF attack work: from malicious page to a request in the user's name

Why does the browser automatically send cookies?

When a user logs in, the site usually creates a session and associates it with the browser via a cookie. For subsequent requests to the same domain, the browser automatically attaches the cookie, so the user doesn't have to re-enter credentials for every action.

A CSRF attack leverages this behavior. A third-party page can attempt to initiate a request to the site where the user is already authenticated. If conditions permit the browser to send session cookies with it, the server sees valid authorization and may treat the request as legitimate.

The key issue is that having the right cookie confirms the session, but doesn't prove the user actually intended the specific action. If the application lacks extra verification, an attacker can exploit this gap between authentication and intent confirmation.

Example of a CSRF attack

Imagine a service where authenticated users can change account settings. If the server accepts such data changes based solely on an active session, a third-party page could theoretically trigger the same request.

The user just opens another site, while the browser interacts with the target service in the background. To the server, the request looks as if it came from its logged-in client.

The attacker doesn't necessarily get access to the server's response or the account's content. In classic CSRF, the main goal isn't to read someone else's data, but to force the system to perform an action on the victim's behalf.

Which actions are especially dangerous?

The most critical are requests that change the system's state: updating contact info, security settings, profile parameters, or performing actions in an admin panel.

The risk is especially high if such operations don't require extra confirmation and are performed immediately upon receiving a request. The more privileges the user has, the greater the potential damage: CSRF in a regular account and CSRF in an admin account can have vastly different impacts.

That's why important operations shouldn't rely solely on having an active session. The server needs additional evidence that the request came from a trusted interface and was genuinely initiated by the user.

CSRF token: how a site distinguishes a real request from a fake one

What is a CSRF token?

A CSRF token is an extra value the server expects with any sensitive request. It's usually generated specifically for the user, session, or form, and delivered to the page where the action is performed.

When the user submits a form or changes settings through the site's normal interface, the browser sends the token back to the server, which compares it to the expected value and only performs the operation if it matches.

This makes an active session alone insufficient. Even if the browser automatically attaches a session cookie, a request without the correct CSRF token is rejected.

Why can't an attacker just send the right token?

A third-party site shouldn't have free access to the contents of another domain's page. While it can try to initiate a request, it usually can't read the CSRF token from the target service's form and insert it into a forged request.

This is the main difference from standard cookies. Session cookies are often sent automatically by the browser according to their settings, but a CSRF token must be explicitly included by the application itself.

If the token's value can't be guessed and the server checks it before performing an operation, forging a request becomes much harder. Simply being logged in isn't enough.

Other ways to protect against CSRF

Additional protection can come from cookie settings. The SameSite attribute restricts cookie sending in cross-site scenarios, reducing the likelihood that a third-party page can use the user's active session.

The server can also check the Origin or Referer headers to determine where a request originated. These checks are useful as an extra layer of security, especially for actions that should only be performed from the service's own pages.

For the most sensitive operations, repeat identity verification is required: re-entering a password, using a one-time code, or confirming the operation separately. In this way, even having an active session and attempting to forge a request shouldn't automatically lead to critical changes.

CSRF vs XSS: what's the difference?

CSRF exploits the site's trust in the browser

During a CSRF attack, the perpetrator tries to exploit an existing user authorization. The browser sends a request to the site with session cookies, and the server may treat it as an action by the account owner.

The key feature of CSRF is that malicious code doesn't have to run within the target site itself. The attack can start from a third-party page that tricks the browser into contacting another service in the user's name.

XSS exploits the user's trust in the site

XSS, or Cross-Site Scripting, works differently. The problem arises when a site allows the injection and execution of foreign JavaScript within its pages.

If such a script runs, it gains access to everything the browser allows for that site. Depending on the vulnerability type, this can let it alter page content, intercept user actions, or make requests on the user's behalf.

In CSRF, the attacker usually doesn't get direct access to the content of the target site's page. The goal is to make the browser send a specific request. In XSS, malicious code runs inside the trusted site, so the attack's potential is much greater.

Why protecting against one attack doesn't prevent the other

CSRF tokens are effective against forged requests from third-party sites, but don't solve XSS. If an attacker manages to run JavaScript directly on a vulnerable application's page, such a script can often interact with the site's interface and its security mechanisms.

The opposite is also true. XSS protection-using data escaping, input filtering, and Content Security Policy-doesn't replace the need to validate CSRF tokens and configure SameSite cookies.

So, CSRF and XSS are different classes of web vulnerabilities. They can lead to similar consequences, such as actions performed on behalf of a user, but use different mechanisms and require different defenses.

How to protect your site against CSRF attacks

Check all requests that modify data

Protecting against CSRF starts with proper web application logic. Requests that change user data or system state shouldn't be processed just because the browser sent a valid session cookie.

It's especially important not to use GET requests for actions that change anything. GET should be for retrieving data, while changing settings, deleting info, processing transactions, and other such actions should use POST, PUT, PATCH, or DELETE methods, along with extra request validation.

However, choosing the right HTTP method alone isn't enough. If the server still trusts only the active session, the CSRF vulnerability may persist. Sensitive requests should be separately validated for origin or include a confirming value.

Use CSRF tokens and SameSite cookies

One of the main protection methods is CSRF tokens. The server generates an unpredictable value and expects it with each request. A third-party page usually can't guess the right token, so even with an active session, a forged request is rejected.

The SameSite cookie attribute provides an additional layer of defense. It restricts cookie transmission in cross-site scenarios, lowering the chance that the browser will automatically attach authentication data to a request initiated by another site.

CSRF tokens and SameSite should be seen as complementary, not interchangeable, solutions. The token confirms the legitimacy of the request, while SameSite restricts the automatic sending of cookies across sites.

CSRF is just one type of web vulnerability. For example, in SQL injection, the attacker targets the application's database queries rather than the user's browser. For more details, read How SQL Injection Works and How to Protect Your Website.

Extra checks for critical operations

For especially important actions, a single CSRF token check may not be enough. Changing passwords, linking new recovery methods, managing permissions, or other critical tasks may require repeat identity verification.

This could mean re-entering the password, providing a one-time code, or confirming the action separately. This reduces the risk that an accidentally sent or forged request will lead to major account changes.

The server can also analyze Origin and Referer headers. These help determine where the request came from and reject those from unexpected sources. However, these should be used as supplementary, not the only, protection mechanism.

Reliable protection relies on several layers: correct use of HTTP methods, CSRF tokens, SameSite cookies, checking request origins, and requiring extra confirmation for critical actions.

Conclusion

A CSRF attack doesn't crack passwords-it exploits the site's trust in an already authenticated browser. If a user is logged in and the server considers an active session enough for any action, a third-party page can attempt to trigger requests on their behalf.

The main defense is built around CSRF tokens, which let the server verify that a request was generated by the application itself. SameSite cookies, checking Origin and Referer, correct HTTP methods, and additional confirmation for critical operations are also important.

The key rule for developers: an active session alone doesn't mean the user truly initiated the request. If your application modifies data, the server should always check the legitimacy of such actions separately.