CSRF testing that proves a real state change
Cross-site request forgery (CSRF) makes a logged-in user's browser fire a state-changing request they never intended — changing an email, transferring funds, adding an admin — just by visiting an attacker's page. Sintropyc tests which of your actions actually lack protection and proves each with a working cross-site request.
How CSRF works
The browser attaches your cookies to every request to your site, even one triggered from another origin. If a state-changing endpoint relies only on that cookie — with no anti-CSRF token, no origin check, no non-cookie proof of intent — an attacker's page can make the request on the victim's behalf.
Where CSRF protection quietly fails
- State-changing
GETrequests, orPOSTforms with no anti-CSRF token - Tokens that are present but never validated, or shared / predictable across users
- APIs relying on cookies for auth without
SameSiteor an origin / referer check SameSite=Nonecookies, or an exemption added for a third-party integration and never removed
How Sintropyc tests it
Sintropyc is an autonomous AI penetration testing agent. It signs in as real users across different roles, drives your product the way a customer would, and proves every finding with a working exploit — never a scanner guess. Each finding is checked by a human before it reaches you, comes with the exact fix, and is attacked again after you ship it to confirm it held.
For CSRF, Sintropyc identifies state-changing actions, strips or forges the anti-CSRF token, and replays each from a cross-site context to see whether the action still completes. A finding is reported only when the request actually changes state without a valid token — proven, with the request that worked.
If your API authenticates by cookie (common in same-domain SPAs), it's a CSRF candidate unless SameSite and origin checks are correct. Token-in-header auth is largely immune — Sintropyc confirms which model you actually have.
What you get
- Every state-changing action checked for real anti-CSRF protection
- Proven CSRF — the cross-site request that changed state, not a missing-header guess
- The fix (anti-CSRF tokens,
SameSite, origin validation) per finding - A retest after you ship it
Common questions
Doesn't SameSite=Lax fix CSRF by default?
It helps a lot in modern browsers, but it isn't complete — GET-based state changes, top-level navigations, SameSite=None exemptions and older clients still leave gaps. Sintropyc tests whether you're actually protected.
We're an API with token auth — are we affected?
If auth is a bearer token in a header (not a cookie), CSRF generally doesn't apply. If any flow falls back to cookies, it can. Sintropyc confirms your real auth model instead of assuming.
Is testing safe?
Yes — proof uses benign, reversible actions on test accounts and the smallest change needed to demonstrate the flaw.