What Is Cross-Site Request Forgery (CSRF) and How Do You Prevent It?

Your user signs in to your web application, then opens a new tab and lands on a page an attacker built. Hidden inside the page is a request aimed straight at your site. The browser sends it along with the user’s valid session cookie, and your server reads it as a genuine action. A password changes. An email address gets rewritten. Funds move. The user approved none of it. This is cross-site request forgery, and it turns your own signed-in user into the tool used against your application.

Cross-site request forgery, shortened to CSRF, tricks a signed-in user into sending a request the user never meant to send. The attack rides on one fact about browsers. They attach your session cookie to every request headed for your domain, even requests fired off by another site. Your server sees a valid cookie and acts. The Canadian Centre for Cyber Security points software vendors toward secure design and development as the baseline for closing weaknesses like this one, in its joint guidance on a software security code of practice. The flaw lives in how your application trusts a request, not in the user’s behaviour.

How cross-site request forgery works

CSRF works because your application has no reliable way to tell a request the user chose to send apart from one an attacker forged. Picture a banking app with a form to move funds. When a signed-in user submits the form, the browser sends the request with the session cookie, and the transfer goes through. An attacker studies the form, then builds a copy on a site of their own. The copy fires the same request, often from an invisible form or an image tag, the moment the victim loads the attacker’s page. Because the victim still holds a live session with your site, the browser attaches the cookie, and your server completes the transfer with no idea anything went wrong.

What makes an application open to CSRF

Three conditions line up in every CSRF attack. First, the request changes state on the server, such as a transfer, a password reset, or an account update. Second, the application leans on session cookies alone to prove who is asking, with no extra check tied to the request itself. Third, the request holds no value an attacker fails to guess or forge. Remove any one of the three and the attack falls apart. Most defences work by breaking the third condition, adding a secret the attacker has no way to predict.

Why CSRF still deserves your attention

CSRF has sat on the OWASP list of web application risks for years because it keeps showing up in real code, often in features built long ago. The payoff for an attacker is direct. One forged request against an admin account resets credentials or creates a new privileged user, and the attacker owns the application. Canadian organizations already pay a steep price when web attacks land. The 2026 IBM Cost of a Data Breach Report put the average Canadian breach at a record 7.11 million dollars, with 205 days from first intrusion to containment. A single state-changing endpoint left open to forgery is enough to start a loss of this size.

How you prevent cross-site request forgery

You close CSRF by proving each state-changing request came from your own application. The primary control is the anti-CSRF token, known as the synchronizer token pattern. Your server generates a secret, unpredictable token, ties it to the user’s session, and plants it in a hidden field or a custom header. Every request to change data carries the token. A request with a missing or wrong token gets rejected. An attacker’s forged page has no way to read the token, so the forged request dies at the door. The OWASP Cross-Site Request Forgery Prevention Cheat Sheet lays out this pattern and the full set of supporting controls.

Layer more defences on top. Set the SameSite attribute on your session cookies to Strict or Lax, so the browser withholds the cookie on requests coming from other sites. Verify the Origin or Referer header on sensitive requests, and reject anything from an unexpected source. Demand re-authentication or a one-time confirmation for high-risk actions such as changing a password or moving money. Lean on the CSRF protection built into your web framework rather than writing your own, since the mainstream frameworks ship tested defences. Keep in mind too: a cross-site scripting flaw defeats every CSRF token, so fixing injection bugs protects this layer as well.

Build the team who designs these flaws out

Tools flag some forged-request flaws. Trained developers stop writing them. The Certified Secure Web Application Engineer path teaches developers to build state-changing features with anti-CSRF tokens and sound session handling from the first line of code. The Certified Web Security Engineer track extends the skill across the full application stack. On the testing side, the Certified Professional Ethical Hacker program shows your testers how attackers find and abuse CSRF, so they catch it before a criminal does. The Certified Penetration Testing Engineer path drives this testing deeper, with hands-on labs against live web targets. Mile2 maps each course to a working role, so your people apply the skill the week they finish.

Cross-site request forgery survives because applications keep trusting a cookie to prove intent. The fix is well understood and within reach. Add anti-CSRF tokens to every state-changing request, set SameSite on your cookies, check the request origin, and demand confirmation for the actions worth protecting. Then put trained developers and testers on the work so the flaw never ships. Attackers probe Canadian web applications daily, hunting for the one form left open. Close it first, and their forged request has nowhere to go.