CSRF: understanding request forgery
CSRF (Cross-Site Request Forgery) tricks an authenticated user into performing, without their knowledge, an action on a web application. It is a discreet vulnerability, sometimes with serious consequences, but fortunately simple to fix once understood.
What is a CSRF vulnerability?
A CSRF vulnerability hijacks the trust relationship between a browser and a server. The attacker's objective: force an already authenticated user to perform a specific action without realizing it: change a password, modify personal information, approve a sensitive operation.
In practice, the attacker tricks the victim into loading a malicious page. That page then sends requests via the victim's browser, as if they were legitimate actions. If the victim has administrator rights, the entire application may be compromised. To increase the chances of success, the attacker often relies onsocial engineering, for example a link sent through phishing.
A key point: CSRF generally targets modification requests (rather than direct data theft), because the attacker cannot see the response to the forged request. It remains a classic link in account takeover scenarios.
What conditions allow a CSRF attack to succeed?
Cookie-only authentication
The application relies solely on cookies to authenticate the user: the browser sends them automatically, even for a request triggered by a third-party site.
Predictable parameters
Sensitive requests contain no unpredictable value: all their parameters can be guessed or reconstructed by the attacker.
Valuable functions to target
The application exposes high-impact actions: password changes, data modifications, operations linked to elevated privileges.
A trapped user
The victim, already logged in, is led to load a malicious page, often through an innocent-looking link received by e-mail or message.
Two effective countermeasures
The good news: CSRF is relatively simple to counter. Two measures work together. The anti-CSRF token: a unique, random value generated server-side and required for each sensitive request, impossible for the attacker to guess. Many frameworks (Django, Laravel…) include it by default. The SameSite attribute on cookies: it prevents session cookies from being sent when a request does not originate from the application's domain. However, be careful: SameSite does not cover subdomains, which can leave a gap if a subdomain is compromised.
Verify rather than assume
Protection that is “enabled by default” is not always applied everywhere: a forgotten route, an exposed API or an overly permissive SameSite configuration can be enough to reopen the vulnerability. The only way to be certain is to actually test sensitive functions as part of an intrusion test or an application security process.
Protect yourself, step by step
Enable anti-CSRF tokens
On all modification actions: a unique and unpredictable token for each request, verified server-side.
Configure the SameSite attribute
On session cookies, to block requests initiated from another domain, while taking subdomains into account.
Rely on framework protections
Verify that anti-CSRF middlewares are active everywhere, and do not disable them “to move faster.”
Test sensitive functions
A pentest confirms that critical workflows are truly protected, including on APIs.
Raise awareness about malicious links
CSRF often starts with a click. Awareness training reduces the likelihood of triggering it.
Why get support from BCIT?
Concrete testing
We truly put your sensitive functions to the test rather than relying on “default” protections.
Clear fixes
Recommendations your development teams can apply directly, prioritized by impact.
A comprehensive view
From website security to audits, we cover the full chain.
Not ready to talk yet? Discover our cybersecurity assessment →
Are your sensitive functions truly protected? 🚀
Let's take 15 minutes to review your applications' exposure to CSRF attacks and define the priority checks.
CSRF: understanding request forgery
CSRF (Cross-Site Request Forgery) tricks an authenticated user into performing, without their knowledge, an action on a web application. It is a discreet vulnerability, sometimes with serious consequences, but fortunately simple to fix once understood.
What is a CSRF vulnerability?
A CSRF vulnerability hijacks the trust relationship between a browser and a server. The attacker's objective: force an already authenticated user to perform a specific action without realizing it: change a password, modify personal information, approve a sensitive operation.
In practice, the attacker tricks the victim into loading a malicious page. That page then sends requests via the victim's browser, as if they were legitimate actions. If the victim has administrator rights, the entire application may be compromised. To increase the chances of success, the attacker often relies onsocial engineering, for example a link sent through phishing.
A key point: CSRF generally targets modification requests (rather than direct data theft), because the attacker cannot see the response to the forged request. It remains a classic link in account takeover scenarios.
What conditions allow a CSRF attack to succeed?
Cookie-only authentication
The application relies solely on cookies to authenticate the user: the browser sends them automatically, even for a request triggered by a third-party site.
Predictable parameters
Sensitive requests contain no unpredictable value: all their parameters can be guessed or reconstructed by the attacker.
Valuable functions to target
The application exposes high-impact actions: password changes, data modifications, operations linked to elevated privileges.
A trapped user
The victim, already logged in, is led to load a malicious page, often through an innocent-looking link received by e-mail or message.
Two effective countermeasures
The good news: CSRF is relatively simple to counter. Two measures work together. The anti-CSRF token: a unique, random value generated server-side and required for each sensitive request, impossible for the attacker to guess. Many frameworks (Django, Laravel…) include it by default. The SameSite attribute on cookies: it prevents session cookies from being sent when a request does not originate from the application's domain. However, be careful: SameSite does not cover subdomains, which can leave a gap if a subdomain is compromised.
Verify rather than assume
Protection that is “enabled by default” is not always applied everywhere: a forgotten route, an exposed API or an overly permissive SameSite configuration can be enough to reopen the vulnerability. The only way to be certain is to actually test sensitive functions as part of an intrusion test or an application security process.
Protect yourself, step by step
Enable anti-CSRF tokens
On all modification actions: a unique and unpredictable token for each request, verified server-side.
Configure the SameSite attribute
On session cookies, to block requests initiated from another domain, while taking subdomains into account.
Rely on framework protections
Verify that anti-CSRF middlewares are active everywhere, and do not disable them “to move faster.”
Test sensitive functions
A pentest confirms that critical workflows are truly protected, including on APIs.
Raise awareness about malicious links
CSRF often starts with a click. Awareness training reduces the likelihood of triggering it.
Why get support from BCIT?
Concrete testing
We truly put your sensitive functions to the test rather than relying on “default” protections.
Clear fixes
Recommendations your development teams can apply directly, prioritized by impact.
A comprehensive view
From website security to audits, we cover the full chain.
Not ready to talk yet? Discover our cybersecurity assessment →
Are your sensitive functions truly protected? 🚀
Let's take 15 minutes to review your applications' exposure to CSRF attacks and define the priority checks.