Cross site request forgery used to be one of the headline web vulnerabilities. Modern frameworks ship with sensible defaults that make it harder to introduce CSRF accidentally, and a generation of developers has grown up assuming the framework has it covered. That is mostly true and occasionally catastrophically wrong, because the assumption only holds while the framework defaults are left alone.
SameSite Cookies Are Not Universal Protection
The introduction of SameSite cookie attributes pushed back the threat significantly. A cookie marked SameSite=Lax will not be sent on most cross site requests, which neutralises the classic CSRF attack pattern. Set the attribute wrong, support older browsers, or rely on a header-based authentication scheme such as a bearer token and the protection evaporates. A capable web application pen testing will validate which protections are actually in force, not which protections the framework claims to support.
CORS Misconfigurations Reopen The Door
A common mistake is to relax CORS policies to make development easier and then forget to tighten them in production. An overly permissive policy that allows credentials from any origin effectively recreates the CSRF risk that SameSite was meant to handle. Worse, it does so on the API surface where the sensitive operations actually live. Review CORS configuration as part of every deployment.
Expert Commentary
William Fieldhouse, Director of Aardwolf Security Ltd
A pattern we see repeatedly is teams who disabled CSRF tokens on the assumption that SameSite cookies and JWT authentication made them unnecessary. They are right about the classic browser attack and entirely wrong about the modern variants that involve service workers, custom protocol handlers and embedded WebViews.
Defence In Depth Wins Here Too
A modern application should layer CSRF defences. SameSite cookies, CSRF tokens for state-changing operations, proper CORS configuration on APIs and per-action authentication confirmation for high-value operations all contribute. None of these is fully sufficient on its own. The layered approach survives the inevitable mistake in any one control. A focused security review should examine each layer rather than confirming the presence of any single one. Worth running the full layered review periodically rather than checking individual controls in isolation. The interactions between layers are where the surprises live, and only an integrated test will surface them with any reliability.
Mobile And Embedded WebView Contexts
Mobile applications that embed a web view, hybrid applications using technologies like Cordova or Ionic and integrated browser plug-ins all run web content in contexts that may not honour SameSite cookies the same way a regular browser would. These are exactly the contexts where authenticated sessions tend to be persistent and high value. A penetration testing quote that explicitly covers these contexts will surface gaps that standard browser testing misses.
The CSRF threat did not disappear. It moved to the places defenders stopped looking. CSRF protection remains worthwhile and continues to evolve. Keep an eye on the platform features that arrive each year, because some of them genuinely shift the picture. Worth refreshing your CSRF defences every couple of years as the browser ecosystem and the frameworks underneath your application both continue to mature. Web application security is a discipline that rewards patient investment. The teams that treat it as ongoing work consistently outperform the ones that treat it as a project with an end date.