What Is CSRF and How Can You Prevent It?
Author: Domeny.ForSale editorial team Published
In brief: CSRF is an attack in which another website tricks a logged-in user’s browser into sending an unwanted request to a different service. If that service checks only whether the user is logged in, it may perform an operation without their informed consent. Protection rests on application-side safeguards: CSRF tokens, appropriate cookie settings and checks on where requests originate.
How CSRF works: an online store admin panel example
CSRF stands for Cross-Site Request Forgery. The attack exploits the fact that a browser can automatically attach a session cookie to requests sent to a particular service. This cookie lets the server recognise a logged-in user without asking for their password again.
Imagine you manage an online store and have its admin panel open. In another tab, you visit a page created by an attacker. That page attempts to send the panel a request to change the email address associated with your account.
If the browser attaches the session cookie and the panel performs no additional check on the request’s authenticity, the server may treat it as your decision. The attacker does not need to know your password or read the cookie: it is enough for the browser to use the cookie when sending the request.
It is a little like someone submitting an instruction with your stamp automatically attached. The system recognises the stamp but does not check whether you actually want that particular operation carried out.
When an attack can succeed and what does not stop it
A typical CSRF attack requires several conditions: the user has an active session, the browser automatically sends authentication credentials, and the application accepts a predictable request that changes the account’s state. This might involve changing details, adding a user or deleting an entry. The consequences depend on the operations available and the victim’s permissions.
The attacker usually does not need to read the server’s response. The browser may prevent the other website from reading data from the panel, yet still allow certain requests to be sent. This is why the same-origin policy, which restricts scripts’ access to resources from other origins, is no substitute for CSRF protection.
HTTPS does not solve this problem either. It encrypts the connection and protects data in transit, but does not confirm that the user knowingly requested the operation. Simply using POST instead of GET is not enough either: another website can submit an ordinary POST form.
CSRF is not the same as XSS. XSS involves running unwanted code in the context of a trusted website, whereas CSRF exploits the service’s trust in requests from the user’s browser. However, an XSS vulnerability can undermine CSRF protection, for example by allowing an attacker to read the token.
How to protect an application against CSRF
The safest starting point is the protection built into your framework. Enable it and make sure it covers all operations that change data, not just the login form.
- Validate the CSRF token. This is an unpredictable value that the application places in a form or provides for submission in an appropriate header. The server checks it before performing the operation. In a common implementation, the token is tied to the session; another website should not be able to read or guess it. The token should not appear in the URL.
- Set the session cookie’s SameSite attribute. This restricts the sending of the cookie in cross-site contexts. Lax and Strict impose different levels of restriction, so test your choice with login flows and integrations. SameSite is a layer of protection, not an unconditional replacement for a token.
- Check the request’s origin. The Origin header, and in a suitably designed mechanism also Referer, helps establish where a request comes from. Compare its value against precisely defined allowed addresses, rather than merely looking for part of a domain name.
- Do not change data through GET. Opening a link should not delete an account or confirm an order. Operations that change data should use the appropriate methods and still undergo CSRF checks.
For particularly sensitive actions, require reauthentication or a separate confirmation. Session cookies should also have appropriate Secure and HttpOnly attributes, although neither prevents CSRF on its own.
Does an API need protection too?
An API, an interface that allows programs to communicate, can also be vulnerable to CSRF if it uses a session authenticated by a cookie. Returning a response in JSON format does not, by itself, provide security.
When the client explicitly adds an access token to the Authorization header and the browser does not attach it automatically, the typical CSRF mechanism generally does not apply. This does not, however, mean the application is immune to token theft or XSS. CORS, the mechanism governing access across origins, is not a standalone defence against CSRF either.
What to check in your own service
Start with one operation, such as changing an email address. Using a test account, in your own environment or with the owner’s permission, check that a request with no CSRF token or an invalid token is rejected and genuinely leaves the data unchanged. Then check the cookie settings and any other routes that perform the same operation.
If you use an off-the-shelf system, confirm how its protection works in the official documentation for your version and installed extensions. As a user, you cannot fix missing server-side safeguards; you can reduce the risk by logging out after using a sensitive admin panel. As an application owner, start by reviewing operations that change data: these require checks to establish whether the request really comes from an authorised interface.
See also: What does www mean?
Read also
