CSRF detection was a straightforward exercise in 2012: check whether state-changing endpoints required a CSRF token. By 2026 the landscape is very different. SameSite=Lax is the browser default, fetch metadata headers change the threat model, REST APIs often dismiss CSRF as irrelevant, and single-page applications handle authentication in ways that confuse traditional CSRF reasoning. The result: CSRF findings in modern codebases are often either false positives (protection exists in a layer the scanner didn't check) or false negatives (protection is absent in a form the scanner didn't recognise). Griffin AI and Mythos-class general-purpose tools handle this landscape differently.
What CSRF actually requires in 2026
Three considerations that modern CSRF analysis needs to handle:
- SameSite cookie behaviour. Most major browsers default cookies to SameSite=Lax, which provides substantial implicit CSRF protection for most traditional forms. Analysis that ignores SameSite will flag endpoints that browsers protect.
- Framework-level protection. Spring Security, Django, Rails all provide default CSRF middleware. Analysis needs to recognise the middleware as applied.
- Non-traditional authentication. JWT in Authorization header, OAuth bearer tokens, custom header-based auth — these are immune to traditional CSRF because the authentication is not cookie-based.
A scanner that doesn't reason about all three produces findings that read like CSRF vulnerabilities but aren't.
Where pure-LLM analysis struggles
Mythos-class tools can recognise CSRF patterns from training data. The breakdown happens at the framework-awareness layer:
- Does the middleware chain for this route actually include CSRF protection?
- Does this SameSite=Lax cookie protect this specific flow given the request method?
- Does this endpoint use bearer-token auth or cookie-based auth?
These are multi-file, multi-framework reasoning tasks. Pure-LLM analysis produces inconsistent output.
How Griffin AI handles it
Three deterministic steps:
Middleware chain analysis. For frameworks with known CSRF middleware (Spring Security's CsrfFilter, Django's middleware, Rails's protect_from_forgery), the engine verifies the middleware is in the chain for each state-changing endpoint. Exemptions (@csrf_exempt, skip_before_action :verify_authenticity_token) are surfaced.
Authentication scheme detection. For each endpoint, the engine identifies the authentication mechanism: cookie-based, bearer-token, custom header. Bearer-token endpoints are correctly classified as CSRF-immune at the transport layer.
Cookie scope awareness. The engine tracks SameSite, HttpOnly, and Secure attributes on session cookies and factors them into the CSRF risk assessment.
The output: a CSRF finding is surfaced only when all three layers actually fail. False positive rate on modern codebases drops substantially.
A concrete example
A FastAPI service uses JWT bearer tokens in the Authorization header. Traditional CSRF scanners flag every POST endpoint as "no CSRF token found — potential CSRF vulnerability."
Griffin AI recognises the authentication scheme as bearer-token, classifies the endpoint as CSRF-immune at the transport layer, and suppresses the false positive. If the same service exposes a cookie-authenticated admin endpoint, Griffin correctly flags that specific endpoint.
A Mythos-class tool reasoning at the endpoint level without framework-awareness more commonly produces the false positive.
What to evaluate
Three concrete checks:
- Show the platform a modern FastAPI or Express application with JWT bearer-token auth. Is CSRF correctly suppressed?
- Show a Spring application with a CSRF-exempt endpoint. Is the exemption correctly flagged as a risk?
- Show a SameSite=Lax cookie-based app. Is the SameSite protection correctly factored in?
The answers separate modern-CSRF-aware tools from legacy-CSRF scanners.
How Safeguard Helps
Safeguard's CSRF detection is built around framework-awareness, authentication-scheme detection, and cookie-scope analysis. The result is CSRF findings that reflect the 2026 threat model rather than the 2012 one. For modern codebases using JWT bearer-token auth, SameSite cookies, and framework-level protection, this precision eliminates the false positives that plague legacy CSRF scanners.