TL;DR: CSRF forges authenticated browser actions while XSS executes attacker script in the victim’s session, according to Aptori’s analysis of common web application flaws. The distinction matters because one abuses trust in requests and the other abuses trust in rendered content, so the controls must differ.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Aptori's blog post: CSRF and XSS are distinct web-application flaws, with CSRF abusing authenticated requests and XSS abusing script execution.
Why it matters: IAM, application security and API teams need to separate request trust from content trust, because the wrong control leaves one of these attack paths open.
Context
CSRF and XSS are different failure modes in the browser trust model. CSRF exploits the fact that browsers automatically carry authenticated context, while XSS exploits the fact that applications render untrusted input back into a page.
Both flaws matter to identity and session governance because they can turn a legitimate login into an attack path without breaking the password itself. That makes them relevant to session handling, token validation and web application control design.
Defence in depth only works when the layered controls address different trust boundaries instead of assuming one control can cover both request origin and script execution.
Key questions
Q: How does CSRF work in a browser session?
A: CSRF works when a browser automatically includes valid session credentials in a request that the user did not intend to send. The server sees an authenticated request, not the user’s intent, so the action can succeed unless the application checks request origin or requires a per-request token.
Q: How does XSS steal data from a web page?
A: XSS steals data by running attacker-controlled JavaScript inside the page context, where it can read the DOM, form fields, session tokens in storage, and page-generated content. It can then exfiltrate that data through requests, redirects, or DOM manipulation. Input encoding, output encoding, and a restrictive Content Security Policy help prevent this.
Q: What is the difference between CSRF and XSS in web security?
A: CSRF forges a request that the browser sends in a legitimate session, usually by social engineering the user into loading malicious content elsewhere. XSS injects script into the target application itself and runs inside the vulnerable page. XSS is usually more powerful because it can read page content, steal anti-CSRF tokens, and defeat many CSRF defenses outright.
Q: Why do state-changing requests need separate anti-forgery checks?
A: State-changing requests need separate anti-forgery checks because browsers automatically attach ambient credentials such as cookies, so a malicious site can trigger an authenticated action without reading the response. An origin check, CSRF token, or same-site cookie control verifies the request came from the intended application, not just from an authenticated browser session.
Technical breakdown
How CSRF turns a valid session into an unwanted action
CSRF works when a browser sends an authenticated request to a target application without the user intending that action. The attacker does not need to read the session cookie if the browser automatically attaches it to a cross-site request. The vulnerable condition is not weak login, but a missing check that the request came from the application’s own origin or was intentionally submitted by the user. See the CSRF Prevention Guide.
Practical implication: Validate state-changing requests with anti-CSRF tokens and origin checks so the server can reject forged actions.
How XSS turns untrusted input into code execution
XSS appears when an application accepts input and later renders it in a browser without safe context-aware encoding or sanitisation. The payload then runs in the application’s origin, which lets the attacker read page data, manipulate the interface or steal session-related information. Stored XSS persists in the application, while reflected XSS executes immediately in the response path. See the Cross-Site Scripting (XSS) Prevention Guide.
Practical implication: Encode output by context and restrict inline script execution so untrusted content cannot become active code.
Why browser security controls must separate requests from content
CSRF and XSS are often discussed together, but they protect different layers of the application trust chain. CSRF controls focus on request legitimacy, while XSS controls focus on whether content becomes executable. Confusing them creates false confidence, because a strong token strategy does nothing against script injection and strong output encoding does nothing against forged state-changing requests.
Practical implication: Treat request integrity and content integrity as separate control domains in design, testing and review.
Threat narrative
Attacker objective: The attacker aims to use a legitimate user’s browser context to trigger actions or run code that the user never authorised.
- Entry occurs when an attacker places a forged request or malicious script into a path the application will process, such as a crafted page, comment field or URL parameter.
- Credential or session context is abused when the browser automatically attaches valid authentication data, or when injected script runs inside the victim’s authenticated session.
- Escalation happens when the forged request performs a privileged action or the script manipulates the page, steals data or hijacks the session.
- Impact is unauthorized state change, data theft, session hijacking or user interface manipulation inside the target application.
Breaches seen in the wild
- ASP.NET machine key attacks 2025: Developers copied ASP.NET machine keys from public sources; attackers used one to run Godzilla via ViewState. Microsoft found 3,000+ such keys.
- Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
CSRF and XSS expose two different trust failures, not one shared vulnerability class. CSRF breaks the assumption that an authenticated browser request is user-intended, while XSS breaks the assumption that rendered content is safe to execute. Security teams that collapse them into a single “web risk” category miss the point that one flaw lives in request validation and the other in output handling. Practitioners should separate detection, testing and remediation by trust boundary, not by page type.
Session security fails when the browser is treated as a trustworthy intermediary. In CSRF, the browser faithfully forwards credentials to a site that cannot tell whether the action was deliberate. In XSS, the browser faithfully executes code that should never have become part of the page. The governance gap is not just missing tokens or missing encoding, but over-reliance on browser behaviour as a security control. Teams should review where application logic depends on the client to behave benignly.
Defense in depth only works when each layer addresses a different exploit path. A token layer can block forged state changes, but it cannot stop injected JavaScript from reading page content or manipulating the interface. Likewise, output encoding can stop script execution, but it cannot prove that a request was legitimately initiated. The operational lesson is that layered controls must be orthogonal, with separate testing for request origin, input handling and session handling.
Browser trust abuse remains one of the easiest ways to turn a normal login into an attack surface. That is why CSRF and XSS still matter even in modern frameworks with stronger defaults. Framework defaults reduce friction, but they do not remove the need for explicit checks at the application boundary. Practitioners should treat the combination of authenticated sessions and untrusted content as a standing design review trigger.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: Application Security Guide
What this signals
Request trust and content trust should be governed as separate controls. Teams often test login flows, session handling and rendering paths in the same review, but CSRF and XSS prove those are different attack surfaces. The practical shift is to measure whether the application validates intent at the request layer and safety at the output layer, not whether one control appears to “cover web security.”
Browser defaults should never be mistaken for security boundaries. Cookies, auto-submitted forms and page rendering all do exactly what the browser is designed to do, which is why application logic must enforce the boundary instead. That means practitioners need explicit testing for request origin checks, encoding coverage and page paths that process untrusted input.
Defense in depth fails when one layer is expected to compensate for another layer’s missing check. Output encoding will not stop forged requests, and anti-CSRF tokens will not stop injected scripts. Security programmes should therefore track these as separate defect classes in review, test and remediation workflows.
For practitioners
- Implement request-origin validation for state-changing actions Require anti-CSRF tokens on every operation that changes server state, and verify origin or referer headers where appropriate.
- Apply context-aware output encoding everywhere untrusted data is rendered Use HTML, attribute, JavaScript and URL encoding matched to the sink, and remove any path that renders raw user input into the page. See the Cross-Site Scripting (XSS) Prevention Guide.
- Harden cookie handling for session-bound workflows Set session cookies with HttpOnly and SameSite where the application flow permits it, and test whether login and payment paths still function safely.
- Separate test cases for forged requests and script injection Build security tests that independently exercise CSRF and XSS paths so a pass in one control does not mask a failure in the other.
Key takeaways
- CSRF and XSS succeed through different trust assumptions, so a single generic web defence strategy leaves gaps.
- CSRF primarily abuses authenticated request handling, while XSS primarily abuses rendering of untrusted content.
- Practical protection requires separate controls for request legitimacy, output encoding and session handling.
Related NHI Mgmt Group resources: CSRF Prevention Guide · Cross-Site Scripting (XSS) Prevention Guide · Defence in Depth Guide · Application Security Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Unsafe request handling and rendering controls create the conditions for both CSRF and XSS. |
| Recommendation — Audit request handling and response generation for misconfiguration that permits forged actions or script execution. | ||
| OWASP ASVS | V8 — Authorization | CSRF turns authorised sessions into unauthorised actions unless request intent is separately verified. |
| V14 — Data Protection | XSS becomes dangerous when untrusted input is rendered without safe handling in the browser context. | |
| Recommendation — Enforce authorisation checks on state-changing operations and verify that each request is deliberately initiated. Apply context-aware encoding and sanitisation before untrusted data reaches any browser sink. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Forged actions and session abuse show why enforcement must occur at the application boundary, not in the browser alone. |
| Recommendation — Require the application to enforce access decisions on every sensitive operation, independent of client behaviour. | ||
| MITRE ATT&CK | TA0006;TA0009 — Credential Access; Collection | XSS often supports credential theft and data collection once code executes in the victim context. |
| Recommendation — Map script-execution risk to credential access and collection techniques in detection and testing. | ||
Key terms
- Cross-Site Request Forgery: Cross-site request forgery is a technique that tricks a logged-in browser into sending authenticated requests the user did not intend. It matters in NHI-heavy systems because cookie-backed token refresh or session renewal can be abused without ever learning the underlying secret.
- Cross-Site Scripting (XSS): A web application flaw where untrusted input is rendered in a way that causes script to execute in a user’s browser. It usually appears when output encoding, templating, or input handling is inconsistent across code paths and frameworks.
- Same-Site Cookie: A Same-Site cookie limits when the browser sends a cookie in cross-site contexts. It reduces exposure to unsolicited requests by preventing some cross-origin cookie handling, but it is not a complete CSRF control on its own. Teams still need server-side validation for unsafe actions.
- Content Security Policy (CSP): Content Security Policy (CSP) is a browser security control that restricts which sources a web page can load or execute content from. It reduces the impact of cross-site scripting and malicious injection, but only if configured tightly and tested. Defenders should review allowed script, style and connection sources, and watch for policy bypasses or overly broad wildcards.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org