CSRF Explained: How Cross-Site Request Forgery Works

Short answer: Cross-site request forgery (CSRF) is an attack in which a malicious web page makes a visitor’s browser send a request to another site where that visitor is logged in, such as your website’s admin area. Because the browser attaches the login cookies automatically, the site may carry out the action as if the user had asked for it: changing an e-mail address, creating an admin account or deleting content. It is prevented with secret tokens in forms, SameSite cookies, checks on where requests come from, and by keeping software updated.

How a CSRF attack works

Websites remember that you are logged in with a session cookie. Every time your browser sends a request to that site, it includes the cookie, so the site knows who you are. That is convenient, and it is also the weakness CSRF exploits: historically, browsers attached cookies no matter which page started the request.

A typical attack looks like this:

1. An administrator is logged in to the website’s dashboard in one browser tab.
2. In another tab, they open a malicious page, perhaps from a link in an e-mail, a comment or an advertisement.
3. That page contains a hidden form or script that automatically sends a request to the website, for example “change this account’s e-mail address to [email protected]”.
4. The browser sends the request with the administrator’s session cookie.
5. If the website does not verify that the request really came from its own form, it performs the change.

The attacker never sees the password or the cookie. They simply borrow the victim’s logged-in browser for one action. If that action is changing the account e-mail, the attacker can then request a password reset and take over the account.

What an attacker can do with CSRF

The impact depends entirely on what the vulnerable action does and on who the victim is:

• Change the e-mail address or password of an account, leading to takeover.
• Create a new administrator user on a content management system.
• Change settings, such as the site’s contact e-mail, payment details or redirect rules.
• Delete posts, products or files.
• Install or activate plugins, which on a CMS can lead to full control of the site.
• For customer accounts: change delivery addresses, make purchases or send messages in the user’s name.

Against an ordinary visitor, CSRF usually affects only their own account. Against an administrator, it can affect the whole website.

CSRF vs XSS: what is the difference?

The two are related: an XSS vulnerability usually defeats CSRF protection, because code running inside your site can read the tokens. That is one reason defences like a Content Security Policy matter for CSRF too.

Defence 1: anti-CSRF tokens

The classic protection is a secret, unpredictable token included in every form and state-changing request. The server generates it for the logged-in user and checks it when the form is submitted. An attacker’s page cannot read the token from your site, so a forged request arrives without the right value and is rejected.

WordPress implements this with “nonces”: short-lived tokens that core and well-written plugins attach to admin actions and forms. Other frameworks, such as Laravel, Symfony, Django and Rails, include CSRF token handling out of the box. The weak point is custom code and plugins that forget to add or check the token. “Missing nonce check” or “CSRF” appears regularly in plugin security advisories, which is why prompt updates matter; see our safe update strategy.

For developers, the OWASP CSRF Prevention Cheat Sheet describes token patterns and common mistakes in detail.

Defence 2: SameSite cookies

The SameSite cookie attribute tells the browser whether to send a cookie with requests that start on another site:

• Strict: never sent on cross-site requests. Strongest, but users arriving from a link on another site appear logged out on the first page.
• Lax: sent on normal top-level navigation, such as clicking a link, but not on cross-site form posts, images or scripts. A good default for session cookies.
• None: always sent, and must be combined with Secure. Needed only for genuine cross-site use, such as embedded widgets.

Modern browsers, starting with Chrome, treat cookies without a SameSite attribute as Lax by default, which blocks many classic CSRF attacks. But browsers differ in details, and a cookie explicitly set to None gets no protection. Set the attribute deliberately rather than relying on defaults. Our guide to Secure, HttpOnly and SameSite cookie flags explains how to check and set them.

Defence 3: check where requests come from

Browsers include headers that reveal where a request started. Servers can use them as an additional check:

• Origin shows the site that initiated a POST or cross-origin request. If it is not your own domain, reject state-changing requests.
• Sec-Fetch-Site, one of the Fetch Metadata headers, says whether a request is same-origin, same-site or cross-site, and lets servers block unexpected cross-site requests early.
• Referer can serve as a fallback, although it may be missing because of privacy settings or a strict Referrer-Policy.

Two further rules close common gaps. Never change data with a simple GET request, because links and images can trigger GET requests from anywhere. And require the current password or a second confirmation for the most sensitive actions, such as changing the account e-mail or password.

Less obvious CSRF cases

CSRF is usually described with admin actions, but a few other variations are worth knowing:

• Login CSRF. The attacker’s page logs the victim into the attacker’s own account on your site. Anything the victim then enters, such as a card number or a search history, ends up in the attacker’s account. Login forms therefore need CSRF protection too.
• JSON and API endpoints. Developers sometimes assume that APIs accepting JSON are safe. Endpoints that also accept form-encoded data, or that rely only on cookies for authentication, can still be forged.
• Logout and “harmless” actions. Forged logouts or preference changes seem minor, but they can be chained with other weaknesses or used to disrupt users.
• Home routers and internal tools. Admin panels on internal networks that trust anyone on the network are classic CSRF targets, because staff browse the web from the same machines.

The common thread is simple: any action that relies only on a cookie to identify the user needs a second proof that the request was intended.

What website owners can check

You do not need to write code to reduce CSRF risk on your site:

1. Update promptly. Apply CMS, theme and plugin updates, especially those whose changelogs mention CSRF or nonce fixes.
2. Remove unused plugins, which reduces the number of forms and actions that could lack protection.
3. Check your cookies. In browser developer tools, look at your site’s session cookies and confirm they have Secure, HttpOnly and a SameSite value.
4. Separate admin browsing. Use a separate browser profile for administering your website, and log out when finished, so a malicious page in your everyday browsing cannot reach a logged-in admin session.
5. Ask about custom code. If a developer built custom forms or an API for you, ask how CSRF protection is handled.
6. Add clickjacking protection. A related attack tricks users into clicking hidden buttons in a framed page; see X-Frame-Options vs frame-ancestors.

The broader picture of browser-level protections is covered in HTTP security headers explained.

How Site AI Audit helps

Site AI Audit checks your site from the outside for the basics that reduce risk: the SSL certificate and its expiry, the HTTPS redirect, security headers and exposed software versions, together with SEO, speed and e-mail authentication. It does not test your forms for CSRF, which requires a security review or penetration test, but a ranked list of missing headers and outdated software is a sensible place to start. Try a free website check.

Related reading

• WordPress Security Checklist: 20 Steps That Actually Matter
• Website Security Scan vs Penetration Test: What You Need
• Website Security for Small Businesses: Where to Start

The bottom line

CSRF abuses the trust a website places in a logged-in browser. The attacker needs no password, only a victim who visits a malicious page while logged in. Tokens on every state-changing request, SameSite cookies, origin checks and extra confirmation for sensitive actions stop it. As an owner, keep software updated, check your cookie settings and keep admin sessions separate from everyday browsing.

FAQ

What is a CSRF attack in simple terms?

It is when a malicious website makes your browser send a request to another site where you are logged in, so that site performs an action you did not intend, using your existing login.

Do SameSite cookies prevent CSRF completely?

They block many attacks, especially with Lax or Strict, but not every case. Browsers differ in details and some cookies must use None, so tokens and origin checks are still recommended.

Does WordPress protect against CSRF?

WordPress core uses nonces to protect admin actions. Vulnerabilities usually appear in plugins or custom code that forget to add or verify a nonce, so keeping plugins updated is important.

What is the difference between CSRF and XSS?

CSRF sends forged requests from another site without reading your pages. XSS runs the attacker’s script inside your site, where it can read and change content, and it can also defeat CSRF tokens.

Can a security scan detect CSRF vulnerabilities?

External scans can check related settings, such as cookie flags and security headers. Finding CSRF flaws in forms usually requires authenticated testing or a penetration test.