What browser-managed sessions, forged requests, and broken token validation taught me about proving user intent.
It has been a while since the previous article in this series. I did not abandon writing; I simply disappeared into OWASP.
One topic led to another, one lab became five, and suddenly my evenings were full of Burp requests and threat models. I am back now, and CSRF feels like the right place to continue.
Before studying it, cookies were mostly mysterious pieces of text travelling between the browser and the server. I knew that the browser attached them to requests automatically and that applications used them to maintain sessions. I had just never looked much deeper.
CSRF changed that.
It showed me that the browser can send a valid session cookie with a request the user never intended to make. The server sees an authenticated session, but authentication alone does not prove intent.
<h2>What CSRF actually abuses</h2>
Cross-Site Request Forgery tricks an authenticated user’s browser into sending a state-changing request to another application.
Imagine that you are logged in to:
<pre><code>https://bank.example
</code></pre>
The application identifies your session using a cookie:
<pre><code>Cookie: session=eyJ1c2VySWQiOjEyM30
</code></pre>
In another tab, you visit an attacker-controlled page. That page cannot normally read your banking data because of the Same-Origin Policy, but reading the response may not be necessary. It may be enough to make your browser send a request:
<pre><code>&lt;form method=&quot;POST&quot; action=&quot;https://bank.example/account/change-email&quot;&gt;
 &lt;input type=&quot;hidden&quot; name=&quot;email&quot; value=&quot;attacker@example.com&quot;&gt;
&lt;/form&gt;

&lt;script&gt;
 document.forms[0].submit();
&lt;/script&gt;
</code></pre>
If the browser includes your session cookie and the server accepts the request based only on that cookie, the email address may be changed.
The attacker did not steal the password or session value. They borrowed the victim’s authenticated browser.
<blockquote>
A session cookie proves that the browser has an authenticated session. It does not prove that the user intentionally performed the action.
</blockquote>
<h2>“But it uses POST” is not a defence</h2>
<img src="https://media.daily.dev/image/upload/s--JiOLWkx0--/f_auto/v1781181816/ugc/content_477bb3d2-997d-4711-a5f1-e67de0ce42ed?_a=BAMAMiWQ0" alt="38128a40-3806-4bf2-8695-4b3b8114f9c5.png">
I used to associate forged requests mainly with suspicious links and query parameters. A <code>POST</code> request felt more deliberate.
Unfortunately, an ordinary HTML form can submit a cross-site <code>POST</code> request:
<pre><code>POST /my-account/change-email HTTP/2
Host: vulnerable.example
Cookie: session=VALID_SESSION
Content-Type: application/x-www-form-urlencoded

email=new@example.com
</code></pre>
The browser handles the request and may attach the relevant cookie automatically.
Using <code>POST</code> is correct for state-changing operations, but the method describes the operation. It does not prove where the request came from or whether the user intended it.
Using <code>GET</code> for state changes is even worse because links, redirects, and images can trigger it. But changing <code>GET</code> to <code>POST</code> fixes the API semantics, not the CSRF problem.
<h2>Lab one: no defences at all</h2>
My first practical case was an email-change endpoint protected only by the session cookie:
<pre><code>POST /my-account/change-email
Content-Type: application/x-www-form-urlencoded
Cookie: session=...

email=wiener%40normal-user.net
</code></pre>
There was no CSRF token and no additional verification.
I copied the request into an external form, changed the email to a unique value, enabled automatic submission, and delivered the page to the lab victim. The browser supplied the victim’s session cookie and the application processed the update.
It was technically simple but conceptually very useful.
The vulnerable trust decision was:
<pre><code>valid session cookie = intentional account change
</code></pre>
Those two things are not equivalent.
Depending on the endpoint, the impact could range from an unwanted preference change to account takeover through password recovery abuse.
<h2>CSRF tokens: presence is not enough</h2>
<img src="https://media.daily.dev/image/upload/s--lRQquOw---/f_auto/v1781181842/ugc/content_635a222a-c25f-43cc-aeaf-9a4228c21922?_a=BAMAMiWQ0" alt="16236ef7-adf5-4c1c-846e-4c6d702c6230.png">
A common defence is to include an unpredictable value in the form:
<pre><code>&lt;input type=&quot;hidden&quot; name=&quot;csrf&quot; value=&quot;RANDOM_TOKEN&quot;&gt;
</code></pre>
The server must verify that the token is:
<ul>
<li>present,</li>
<li>unpredictable,</li>
<li>valid,</li>
<li>associated with the current authenticated session.</li>
</ul>
That final requirement is easy to miss.
A token can look random and still be useless if any valid token works for every user. An attacker can log into their own account, obtain a fresh token, place it in a malicious form, and submit it through the victim’s browser.
The application sees two individually valid values:
<pre><code>Victim session cookie: valid
Attacker CSRF token: valid
</code></pre>
But it fails to verify that they belong together.
<h2>Lab two: the token belonged to nobody in particular</h2>
The second lab included a CSRF token, so the request initially looked protected:
<pre><code>POST /my-account/change-email
Cookie: session=VICTIM_SESSION

email=test@example.com&amp;csrf=TOKEN
</code></pre>
I used two accounts to test the relationship between the token and the session. A fresh token generated for one account was accepted with the other account’s session.
The interesting part was not only the exploit. It was learning to read the response.
<code>Invalid CSRF token</code> meant the request failed during security validation. A <code>302</code> redirect to <code>/login</code> usually meant that the session was missing or expired. But a business-level message such as <code>Email already in use</code> was useful evidence: the token check had probably passed and the request had reached the update logic.
An error can reveal how far the request travelled through the application.
<h2>What secure validation should look like</h2>
<img src="https://media.daily.dev/image/upload/s--XNh1ldzS--/f_auto/v1781181886/ugc/content_c8530a37-54a0-4d9f-a796-fa98e1316e34?_a=BAMAMiWQ0" alt="ad43ea4c-9d4e-41f0-96d8-eeb0e3d91a6f.png">
A simplified server-side implementation can store a CSRF token in the user’s session and compare it with the submitted value:
<pre><code>import crypto from &quot;node:crypto&quot;;

export function createCsrfToken(req) {
 const token = crypto.randomBytes(32).toString(&quot;hex&quot;);
 req.session.csrfToken = token;
 return token;
}

export function validateCsrf(req, res, next) {
 const submitted = req.body.csrf;
 const expected = req.session.csrfToken;

 if (
 typeof submitted !== &quot;string&quot; ||
 typeof expected !== &quot;string&quot; ||
 submitted.length !== expected.length ||
 !crypto.timingSafeEqual(Buffer.from(submitted), Buffer.from(expected))
 ) {
 return res.status(403).send(&quot;Invalid CSRF token&quot;);
 }

 next();
}
</code></pre>
In production, well-maintained framework middleware is usually safer. The value must still be unpredictable, validated server-side, and connected to the session.
A token that is merely Base64-encoded user information is not unpredictable. Encoding is not security wearing a clever hat.
<h2>Where does the frontend fit?</h2>
CSRF is enforced on the server, but frontend engineers still influence the flow.
A frontend may need to render a server-generated token, include it in state-changing requests, preserve the expected request format, and avoid leaking it into URLs, logs, analytics, or error reports.
<pre><code>await fetch(&quot;/api/account/email&quot;, {
 method: &quot;POST&quot;,
 credentials: &quot;same-origin&quot;,
 headers: {
 &quot;Content-Type&quot;: &quot;application/json&quot;,
 &quot;X-CSRF-Token&quot;: csrfToken,
 },
 body: JSON.stringify({ email }),
});
</code></pre>
A custom header makes a basic HTML-form attack harder because forms cannot set arbitrary headers. The backend must still validate the token, and CORS must not allow untrusted origins to send credentialed requests with that header.
The frontend transports evidence. The backend decides whether that evidence is valid.
<h2>What I now check</h2>
When reviewing a sensitive action, I ask:
<ol>
<li>Does the request change server-side state?</li>
<li>Does authentication rely on cookies?</li>
<li>Can an external HTML form reproduce it?</li>
<li>Is there a CSRF token?</li>
<li>What happens when the token is removed or changed?</li>
<li>Can a token from another session be reused?</li>
<li>Did validation fail, or did the request reach business logic?</li>
<li>Is the endpoint relying on <code>POST</code>, CORS, or <code>Referer</code> as its only protection?</li>
</ol>
<h2>Summary</h2>
CSRF does not require the attacker to steal a session cookie. It abuses the browser’s ability to send that cookie automatically.
<code>POST</code> does not stop forged requests. A token does not help merely because it exists. The server must verify strong evidence connected to the same authenticated session.
In the next part, I will go deeper into the cookie behaviour behind the attack: <code>SameSite</code>, browser and backend interpretations of a request, and a method-override edge case that turned an allowed top-level <code>GET</code> navigation into a state-changing <code>POST</code>.
<h2>My takeaway</h2>
Before this topic, cookies were mysterious text that applications used to remember me. I knew the browser sent them automatically, but I had not thought carefully about the security consequences.
CSRF gave that behaviour a shape. A valid cookie answers, “Which session is this?” It does not answer, “Did the user mean to do this?”
That second question is where the real defence begins.
I’m trying out a more relaxed style for the visuals this time. Do you like them? Let me know in the comments - honest feedback is very welcome!
#<code>security</code> #<code>webdev</code> #appsec <code>#owasp</code>

A practical AppSec learning journal from a Frontend Developer. I share notes, lab write-ups, OWASP topics, Burp Suite practice, and honest thoughts from learning web security step by step.

Application Security Blog

CSRF (Cross-Site Request Forgery) exploits the browser's automatic cookie attachment to forge authenticated requests without stealing credentials. A valid session cookie proves identity, not intent. POST requests alone don't prevent CSRF — HTML forms can submit cross-site POST requests. CSRF tokens must be unpredictable, server-validated, and tied to the specific session; a token valid for any user is useless. Two practical labs demonstrate: (1) no token at all, and (2) a token not bound to a session. Secure implementation uses cryptographically random tokens compared with timing-safe equality. Frontend engineers play a role by including tokens in requests and using custom headers, but backend validation is the real defense. A checklist of questions for reviewing sensitive endpoints is provided.

Key Web Vulnerabilities #5, Part 1: CSRF Is Not About Stealing Cookies