CSRF Defense Configuration Checker Guide: Check the Defenses You Name

Cross-site request forgery, usually shortened to CSRF, is an attack that abuses trust rather than breaking it. The victim is logged into a site, and visits a malicious page, or even a malicious image on an otherwise ordinary page. That page causes the victim's browser to send a request to the trusted site, and the browser helpfully attaches the victim's cookies, so the trusted site sees a request that looks authenticated. If the trusted site acts on the request, the attacker has made it perform an action the user never intended: changing an email address, transferring funds, or deleting data, all with the victim's own credentials. The attack works because browsers attach cookies automatically, and the site cannot tell, from the request alone, whether the user meant to make it.

The CSRF Defense Configuration Checker tool pastes configuration or header notes and checks which common CSRF defenses are mentioned. That description defines both what the tool does and what it cannot do. It reads notes you paste, such as a configuration summary or a header list, and reports which known defenses appear in those notes. It does not inspect your code, it does not test your live site, and it cannot prove a defense is actually active. A defense mentioned in a note may be planned, partially implemented, or fully deployed, and the tool cannot distinguish those states. What it gives you is a coverage review: of the defenses a site should consider, which ones does this note even mention, and which ones are absent from the conversation entirely.

The primary defense is the anti-CSRF token. When a site serves a form, it includes a random, unpredictable token tied to the user's session, and when the form is submitted, the server checks that the token matches. An attacker's page cannot read the token, because the same-origin policy prevents cross-origin pages from reading the site's content, so a forged request arrives without a valid token and is rejected. The token must be random, tied to the session, and checked on every state-changing request, not just on some forms. A token that is predictable, shared across users, or checked only on login forms is a token in name only.

The supporting defenses each close a different gap. SameSite cookies tell the browser not to attach a cookie to cross-site requests, which removes the fuel the attack runs on: without the cookie, the forged request arrives unauthenticated. The strict value blocks cookies on all cross-site requests, while the lax value allows them on top-level navigations such as following a link, which is a deliberate compromise for usability. Origin and referer header checks let the server verify that a request came from its own site, by comparing the request's origin against an expected value, though these checks must be applied carefully, because some browsers and privacy tools suppress the referer header. Requiring custom headers for API requests is another layer, because a simple cross-origin form cannot set custom headers without triggering a preflight check the browser will enforce. No single defense is complete on its own, which is why the coverage view matters: a site should be able to name several defenses, not just one.

A worked example you can follow

Take a sample configuration note that mentions 6 common defenses in total as the reference list: anti-CSRF tokens, SameSite cookies, origin checks, referer checks, custom header requirements, and re-authentication for sensitive actions. The pasted note mentions 4 of them: anti-CSRF tokens, SameSite cookies set to lax, origin checks, and custom header requirements. Count the coverage: 4 mentioned out of 6 in the reference list, which is 4 divided by 6, or about 67 percent mentioned, and 2 defenses, or about 33 percent, absent, namely referer checks and re-authentication for sensitive actions. The absent 2 are not necessarily failures: referer checks may be deliberately omitted because the team distrusts the referer header, and re-authentication may be planned for a later phase. But each absence should have a reason, and the checker's value is in forcing that question for each of the 2, rather than letting them stay unexamined.

Now examine the mentioned defenses for quality, not just presence. The note says SameSite is set to lax. Lax allows cookies on top-level GET navigations, which means a forged top-level navigation could still carry the cookie, though it could not carry out a state-changing POST. If the site has 10 state-changing endpoints and all 10 are POST requests protected by tokens, the lax setting leaves 0 of them exposed through the cookie path, because the token check covers them. But if 2 of the 10 endpoints accept GET requests for state changes, those 2 are exposed, since a GET request with a lax cookie attached and no token check would be acted on. That is 2 out of 10, or 20 percent, of endpoints at risk from a single design choice: state changes over GET. The fix is to move state changes to POST with token checks, which reduces the exposed count from 2 to 0, rather than merely tightening the cookie.

Take a second sample note that mentions only 1 defense out of 6: anti-CSRF tokens. That is 1 divided by 6, or about 17 percent coverage. The token may be well implemented, but the site has no second layer, so a single token implementation flaw leaves it fully exposed. The fix is not to add all 5 missing defenses at once, but to add the highest-value one next, which is usually SameSite cookies, raising coverage from 1 to 2 out of 6, or about 33 percent, and then to verify the token implementation itself, because depth in the primary defense matters more than breadth across the list. Coverage percentages are a triage aid, not a score to maximise blindly; a site with 2 well-implemented defenses is safer than a site with 6 mentioned and none verified.

Mistakes to avoid

The first mistake is treating a mention in notes as proof of implementation. Notes describe intent; only code review and live testing prove a defense is active. The second mistake is relying on a single defense, so one flaw removes all protection. The third mistake is allowing state-changing GET requests, which bypass token checks that are typically applied only to POST forms. The fourth mistake is pasting real secrets, such as session tokens or signing keys, into a checker along with configuration notes. Notes should name defenses and settings, never carry live credentials, because anything pasted into a web page should be treated as potentially retained.

The Cookie Security Checker tool covers the cookie flags that support CSRF defenses, and the Security DNS Checker tool helps with a wider site review, since cookie flags and transport security sit beside CSRF defenses in any serious checklist. For background on reading cookie flags properly, see Cookie Security Flags: Reading Set-Cookie Headers Properly.

Checking the result before you act on it

Treat a coverage result as a review prompt, not a verdict. For each defense mentioned, verify it in code and in live behaviour: submit a form without its token and confirm rejection, check the cookie flags on a real response, and confirm state changes require POST. For each defense absent, record either a reason for omitting it or a plan to add it, so the gap is a decision rather than an oversight. Keep the note, the coverage count, and the verification results together, because a CSRF review that is written down can be repeated, while one that lives only in a checker's output cannot. A defense set that is named, implemented, tested, and documented is a site that can say, with evidence, how it resists forged requests.