What is CSRF?
CSRF, short for cross-site request forgery, is an attack that tricks a logged-in user’s browser into performing an action they never intended. It exploits a simple fact about the web: once you are signed in to a site, your browser automatically attaches your session cookie to every request it sends there, including requests triggered by other websites. CSRF abuses that automatic trust to make your browser carry out state-changing actions on a site where you are authenticated, without your knowledge.
What is CSRF and why does it matter?
The danger of CSRF is that the malicious request comes from a genuine, logged-in session, so to the target site it looks entirely legitimate. An attacker cannot see the response, but they do not need to; the goal is to cause an action. That might mean changing your account email so they can take it over, updating a password, altering settings, making a purchase, or on an administrative account, creating a new admin user. Because the action happens with your real privileges, ordinary authentication does nothing to stop it.
How CSRF works
The attacker builds a page or email containing a hidden request aimed at the target site, such as a form that submits automatically or an image tag pointing at an action URL. When a victim who is logged in to the target site visits that page, their browser fires the request and dutifully includes their session cookie. The target site sees a properly authenticated request and carries out the action. The victim usually notices nothing, because everything happened silently in the background.
CSRF versus XSS
The two are often confused but are different. Cross-site scripting runs attacker code inside your site, while CSRF makes the victim’s browser send a legitimate-looking request from outside. XSS is the more powerful of the two, and notably it can defeat many CSRF defences, which is one more reason to close cross-site scripting holes. Our guide on what XSS is covers that side in detail.
How to prevent CSRF
- Anti-CSRF tokens are the primary defence. Each form includes a secret, unpredictable token that the server checks, so a request forged by another site is missing the token and is rejected.
- SameSite cookies tell the browser not to send your session cookie on cross-site requests, blocking most CSRF at the browser level.
- Checking the origin of requests adds another layer for sensitive actions.
- Re-authentication for high-risk operations, such as changing a password, ensures the real user is present.
CSRF protection in WordPress
WordPress has a built-in defence called nonces, which are single-use tokens attached to forms and action links. Core uses them consistently, and well-written plugins are expected to use them too. As with other vulnerabilities, CSRF holes in WordPress most often appear in plugins and themes that forget to verify a nonce before acting on a request. Keeping components updated, as covered in our guide on WordPress plugin and theme vulnerabilities, closes most disclosed CSRF issues.
How to check your site for CSRF risk
CSRF weaknesses hide in any action that changes data without a proper token, and they are easy to overlook across a busy plugin stack. Run a security scan with EzyAudit AI and we assess the security posture that protects against forged requests, including cookie settings and headers, with clear guidance on anything that needs attention. Review the full list of checks we run. For a thorough technical treatment, the OWASP cross-site request forgery resource is the reference standard.
CSRF turns a user’s own logged-in session against them, but tokens and SameSite cookies make it very hard to pull off. Scan your website now to check your defences.