You built a settings page. It has a form where users change their email address. You tested it, it works, you shipped it.
What you didn't consider is that someone else can submit that form on behalf of your logged-in users. Not from your site. From theirs. And the browser will send the request with your user's session cookie attached like nothing is wrong.
That's Cross-Site Request Forgery. CSRF. One of the oldest web vulnerabilities still landing in production applications every single week.
How the Attack Works
Your settings form probably looks something like this:
When a logged-in user submits that form, the browser sends a POST request to your server with their session cookie. Your server sees the cookie, validates the session, updates the email. Standard stuff.
Now here's the attack. An attacker creates a page on their own domain with this HTML:
When your user visits that page, the hidden form auto-submits. The browser sends the POST request to your server. Because the browser automatically attaches cookies for yourapp.com, the request arrives with a valid session. Your server can't tell the difference between this request and one the user made intentionally.
The user's email is now attacker@evil.com. The attacker requests a password reset. It goes to their inbox. Game over.
Why Your Browser Betrays You
The root of this problem is how browsers handle cookies. When a browser makes a request to a domain, it attaches all cookies for that domain regardless of which site initiated the request. Your server sees a valid session cookie and assumes the request is legitimate.
That means any action your app performs based on cookie authentication alone is vulnerable. Password changes. Email updates. Fund transfers. API calls that modify data. If the request doesn't require anything beyond what the browser automatically sends, an attacker can forge it.
This is not theoretical. OWASP has tracked CSRF for over a decade. In 2025, automated scanners still flagged it in roughly 30% of web applications tested. The attack is old. It still works.
Three Ways to Stop It
Fixing CSRF isn't complicated, but you need at least one of these defenses. Using all three is better.
1. CSRF Tokens
The most common defense. Your server generates a unique, unpredictable token for each session and embeds it in the form. When the form submits, the server checks that the token matches.
Your protected form:
Server side in Express.js:
The attacker can't forge this request because they don't know the token value. They can't read it from your page either, because the browser's same-origin policy prevents cross-domain reads.
2. SameSite Cookies
Modern browsers support the SameSite cookie attribute. It tells the browser to stop sending cookies on cross-site requests.
Strict means the cookie is never sent on cross-origin requests. Period. Lax is slightly more relaxed and allows cookies on top-level GET navigations but blocks them on POST requests from other sites. Most browsers now default to Lax, which helps, but setting it explicitly is still important.
3. Verify the Origin Header
Every POST request includes an Origin or Referer header that tells you where the request came from. Verify it matches your domain before processing anything:
This isn't bulletproof on its own because some proxies strip these headers, but it's a strong additional layer.
The Problem With Manual Checks
You can add CSRF protection to every form in your app today. But will you catch every endpoint? Applications grow. New routes get added. Someone on your team builds an API endpoint that accepts POST requests and forgets to add token validation. Or you add a new feature at 2am and skip the middleware.
CSRF vulnerabilities are exactly the kind of thing that slips through when you're building fast and shipping daily. One missed endpoint on a settings page or a payment flow, and you have a vulnerability that automated bots will find before you do.
Axeploit tests every form and state-changing endpoint in your application for CSRF vulnerabilities, automatically. No configuration. The AI agents submit forms, test token validation, and check cookie attributes across your entire attack surface. If there's a gap, you'll know about it before an attacker does.
Run a scan now: https://panel.axeploit.com/signup
