How to Protect Your Site from CSRF
CSRF (Cross-Site Request Forgery) — attack where an attacker makes a user perform an action on your site (transfer money, change password) via a cross-site request. Mitigation: 1) **SameSite cookie** (default Strict/Lax in 2026 browsers), 2) **CSRF token** in forms (synchronizer token pattern), 3) **Check Origin/Referer** headers. Modern frameworks automate this.
Below: step-by-step, working examples, common pitfalls, FAQ.
Step-by-Step Setup
- Set cookies with
SameSite=Lax(default in modern browsers, but explicit is better) +HttpOnly + Secure - For state-changing forms (POST/PUT/DELETE) — add CSRF token field
- Server: generate token per session, store in session, validate on every POST
- For JSON APIs: require custom header (
X-CSRF-Token) — simple requests cannot set it without JS - Check Origin/Referer: reject requests with foreign origin for state-changing endpoints
- Test: fetch from another site → should be blocked by browser CORS + your CSRF check
Working Examples
| Scenario | Config |
|---|---|
| PHP session-based token | <?php
session_start();
if (empty($_SESSION['csrf_token'])) {
$_SESSION['csrf_token'] = bin2hex(random_bytes(32));
}
// Form:
echo '<input type="hidden" name="_token" value="' . $_SESSION['csrf_token'] . '">';
// Validate:
if (!hash_equals($_SESSION['csrf_token'], $_POST['_token'] ?? '')) {
http_response_code(403);
exit('CSRF');
} |
| Django (auto) | # settings.py
MIDDLEWARE = ['django.middleware.csrf.CsrfViewMiddleware', ...]
# In template:
# <form method="post">{% csrf_token %} ... </form> |
| Express.js (csurf) | const csrf = require('csurf');
app.use(csrf({ cookie: true }));
app.get('/form', (req, res) => {
res.render('form', { csrfToken: req.csrfToken() });
}); |
| SameSite cookie | Set-Cookie: session=abc; HttpOnly; Secure; SameSite=Lax
# Lax — allows top-level GET, blocks cross-site POST
# Strict — blocks all cross-site (breaks OAuth callbacks) |
| Origin header check | $allowed = ['https://example.com', 'https://www.example.com'];
$origin = $_SERVER['HTTP_ORIGIN'] ?? '';
if (!in_array($origin, $allowed)) { http_response_code(403); exit; } |
Common Pitfalls
- Static token — predictable. Always random per-session
- Equality via
===— timing attack. Usehash_equals() - SameSite=Strict breaks OAuth/payment redirects. Use Lax for most cases
- Cookie without Secure flag + HTTPS mixed content → can leak in plain HTTP
- CSRF doesn't protect from XSS. XSS bypasses CSRF (attacker script reads token). Fix XSS too
Why teams trust us
How it works
Enter site URL
Security headers analyzed
Get grade A–F
What Does the Security Analysis Check?
The tool checks HTTP security headers, SSL/TLS configuration, server info leaks, and protection against common attacks (XSS, clickjacking, MIME sniffing). A grade fromA to F shows overall security level.
Header Analysis
Checking Content-Security-Policy, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and more.
SSL Check
TLS version, certificate expiry, chain of trust, HSTS support.
Leak Detection
Finding exposed server versions, debug modes, open configs, and directories.
Report with Recommendations
Detailed report explaining each issue with specific steps to fix it.
Who uses this
Security teams
HTTP header audit
DevOps
config verification
Developers
CSP & HSTS setup
Auditors
compliance checks
Common Mistakes
Strict-Transport-Security.Server: Apache/2.4.52 helps attackers find exploits. Hide the version.DENY or SAMEORIGIN.nosniff, browsers may misinterpret file types (MIME sniffing).Best Practices
Content-Security-Policy-Report-Only, monitor violations, then enforce.Server, X-Powered-By, X-AspNet-Version from responses.Get more with a free account
Security check history and HTTP security header monitoring.
Sign up freeLearn more
Frequently Asked Questions
Is SameSite=Lax enough in 2026?
For top-level GET — yes. For POST/PUT/DELETE — Lax blocks cross-site, core CSRF mitigation. But defence-in-depth: token on state-changing forms is mandatory.
API with cookies auth — do I need CSRF?
Yes, if cookies. JWT in header (Bearer) — CSRF ok (attacker cannot set custom header). Cookies — vulnerable without CSRF token.
SPA + JSON API — how?
Double-Submit Cookie: CSRF token in cookie + in request header. Attacker cannot read cookie (SameOrigin), does not know value for header.
How to verify CSRF protection?
Create test page on another domain with <code>fetch('/your-site/action', {method: 'POST', credentials: 'include'})</code>. Should be blocked.