Topic starter
11/11/2026 6:01 pm
TL;DR: 44% of developers follow security best practices for secrets management, according to Aptori’s analysis of common web-application flaws, which mirrors the same behaviour gap seen when CSRF and XSS are treated as interchangeable. Request validation and output handling need separate controls because each flaw breaks a different trust boundary.
Editorial analysis by NHI Mgmt Group, based on content published by Aptori: “CSRF vs XSS: What Is the Difference?”.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
- 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.
Bottom line: CSRF and XSS succeed through different trust assumptions, so a single generic web defence strategy leaves gaps.
Glossary terms: Cross-Site Request Forgery, Cross-Site Scripting (XSS), Same-Site Cookie, Content Security Policy (CSP)
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/11/2026 6:07 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: CSRF and XSS split trust abuse from script execution