When XSS Meets CSRF

Modern web apps often focus on "fixing XSS" or "fixing CSRF" as separate problems. But real attacker paths frequently combine multiple weaknesses. One of the most interesting (and dangerous) patterns is the chain where a reflected XSS vulnerability is used to influence a CSRF-protected action, sometimes bypassing protections not by executing JavaScript, but by leveraging how browsers submit forms.

This article breaks down the mechanics in simple terms: how client-side validation can fail, how reflected input becomes dangerous, why CSP is crucial, and how CSRF tokens change the attacker's goals.

1) Client-side validation isn't security

Many sites validate user input in JavaScript on the page. That validation improves user experience and catches obvious mistakes, but it does not protect the server.

An attacker can:

change input fields (or their types),
alter the payload format,
and submit values that the front-end UI would normally block.

Key takeaway: client-side validation is a speed bump, not a lock.

2) Reflected XSS: "My input comes back to the page"

A reflected XSS vulnerability happens when:

A site takes a value from a request (often a query parameter),
includes it in the response page,
and the browser interprets it in a way that the attacker can control.

At first glance, a payload might "appear" on the page. But whether it becomes code depends on escaping/sanitization.

Escaping vs executing

If the application properly escapes special characters, the browser treats attacker text as plain content — so <script> doesn't run, and event handlers won't fire.

That's a big win: reflected data becomes harmless text.

3) CSP: the browser's second line of defense

Even if an application has a reflective weakness, modern deployments may use Content Security Policy (CSP) to limit what injected code is allowed to do.

CSP can block:

inline scripts,
certain script sources,
unsafe dynamic behaviors.

So an attacker might successfully inject markup, but the browser refuses to execute the JavaScript because CSP denies it.

Key takeaway: CSP can turn "successful injection" into "failed execution."

4) When script execution fails, attackers pivot

If CSP blocks inline JavaScript, attackers often try different routes — anything that doesn't require JavaScript execution.

One common pivot is to use HTML behaviors rather than script blocks. Browsers will often still:

submit forms,
follow links,
navigate to URLs,
or perform request actions depending on which HTML features are allowed and whether policies like CSP restrict them.

This is where the chain becomes interesting: the attacker stops trying to run code and tries to trigger an action.

5) CSRF tokens: why "email change" is hard to fake

Actions like "change email" are protected against CSRF (Cross-Site Request Forgery). The server expects a secret token tied to the user's session.

So even if an attacker can cause the browser to submit a request, they often still need the correct CSRF token.

That turns the attacker's job from:

"make the page show something" to
"make the victim's browser send a valid token back to the server"

6) The strategy change: getting the CSRF token

Some CSRF flows keep tokens hidden in POST bodies, which aren't visible in the URL. That makes token theft harder.

Attackers therefore look for ways to make token values appear in places they can observe — for example, by influencing the request method or how the token is transported.

Once the attacker can obtain the token, the remaining step is straightforward conceptually:

submit the same server endpoint the victim would use,
include the valid CSRF token,
and provide the attacker's desired input (like a new email address).

Key takeaway: CSRF tokens help a lot, but only if they can't be induced to leak or be reused.

The most dangerous attacks are rarely just "one vulnerability." They're often a chain: an input reflection flaw, a policy that blocks script execution, a pivot to form-based behaviors, and finally a CSRF token problem that makes the final action possible.

Understanding how these pieces interact helps teams build layered defenses that survive attacker pivots not just attacks that match the textbook scenario.

Thankyou for Reading:)