Because those issues are mostly control failures, not framework failures. XSS appears when untrusted input reaches the browser unsafely, CSRF appears when state changes are not protected by robust request checks, and IDOR appears when resources are exposed without server-side authorisation. The framework can help, but it cannot enforce application intent by itself.
Why JavaScript frameworks reduce, but do not eliminate, XSS risk
Modern frameworks help by escaping output, templating safely, and discouraging direct DOM manipulation. That lowers the odds of accidental XSS, but it does not remove the root condition: untrusted data still reaches a browser context. Once a developer bypasses the framework, uses raw HTML insertion, or combines framework code with unsafe third-party components, the protection boundary moves back to application design.
Client-side safety also depends on how data is sourced and rendered. If content is pulled from a CMS, user profile field, rich-text editor, markdown renderer, or widget that is not strictly sanitised, the framework can only render what it is given. XSS therefore remains a composition problem, not just a syntax problem. Good guidance from the OWASP API Security Top 10 and the OWASP Non-Human Identity Top 10 is useful here because both show how a safe platform still depends on the trustworthiness of what enters it.
Even when a framework auto-escapes HTML, XSS can reappear through browser APIs, unsafe sinks, legacy helper functions, or component libraries that treat markup as trusted by default. The practical lesson is that framework defaults are a floor, not a complete policy. If the application allows HTML, script-adjacent URLs, or dynamic code-like content, the team still needs explicit sanitisation rules and review of every escape hatch.
Why CSRF still exists after you adopt a framework
Frameworks can make CSRF protection easier, but they cannot infer which requests should change state or which actions deserve a second proof of intent. CSRF is a server-side trust failure: the application accepts a state-changing request without checking that it came from the expected user interaction context. If the backend does not validate tokens, origins, or other request characteristics consistently, the framework cannot compensate.
This is why CSRF often survives in mixed stacks. A team may protect some endpoints with built-in middleware, then expose older routes, custom handlers, or API endpoints that use different assumptions. The risk is highest where browser credentials are sent automatically and the request has side effects. That pattern is common enough to justify looking at the NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST Cybersecurity Framework 2.0 as control-oriented references for access control, request validation, and governance over application behaviour.
Framework support also breaks down when an application mixes browser sessions, APIs, and cross-origin flows. If one code path relies on cookies, another on bearer tokens, and a third on custom headers, the organisation must deliberately decide where CSRF matters and where it does not. The framework can provide primitives, but the application must define trust boundaries and enforce them uniformly across every state-changing route.
Why IDOR remains a server-side authorisation problem
IDOR survives because object access is ultimately decided by the server, not the framework template. A framework may help retrieve objects by route parameter, but it cannot know whether the current user is entitled to read, update, or delete that object unless the application checks ownership, tenancy, role, or policy at the point of access. If the server trusts a predictable identifier alone, the user can often swap one ID for another and reach data they should never see.
This is where many teams overestimate abstraction. Strong routing, ORM helpers, and automatic model binding improve developer speed, but they do not replace per-request authorisation. The safer pattern is to enforce access control where the object is resolved, not after the object is already returned. For teams handling APIs or account data, the OWASP API Security Top 10 is especially relevant because broken object-level authorisation is the exact failure mode behind many IDOR issues.
In practice, IDOR risk rises when identifiers are guessable, access rules are inconsistent across endpoints, or one part of the system assumes a previous check already happened. Frameworks cannot safely infer business ownership, delegation, tenant isolation, or exceptions. Those rules must be explicit, testable, and enforced on every sensitive object path.
Risk and Threat Considerations
The shared risk across XSS, CSRF, and IDOR is false confidence in framework defaults. Attackers do not need to defeat the framework itself if they can reach an unsafe sink, an unprotected state-changing route, or an object lookup that lacks server-side authorisation. The practical threat is not that frameworks are weak, but that applications leave narrow gaps where the framework stops and business logic begins.
Failure mechanism: XSS appears when untrusted content is rendered into the browser without safe encoding or sanitisation, CSRF appears when authenticated requests are accepted without a robust proof-of-intent check, and IDOR appears when object access is authorised by identifier alone rather than by server-side policy.
Impact: These failures can expose sessions, modify data, trigger unauthorised transactions, or reveal records across users and tenants. At scale, the same design mistake can repeat across many routes and components, turning one missed control into a broad application-wide exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V5 — File Handling | XSS often enters through unsafe content handling and rendering paths. |
| V8 — Authorization | IDOR is a direct object-authorization failure at the server boundary. | |
| V10 — OAuth and OIDC | CSRF and browser-session trust boundaries often intersect with federated login and token handling. | |
| Recommendation — Review every untrusted content sink and require safe encoding or sanitisation before rendering. Enforce object-level authorization on every sensitive read and write operation. Validate request origin and session state around browser-authenticated flows. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | IDOR is prevented by enforcing access decisions at the point of object access. |
| SC-18 — Mobile Code | XSS is an untrusted-code execution problem in the browser context. | |
| Recommendation — Enforce server-side access checks for each object and action. Constrain execution of untrusted content and code-like input. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | Least privilege limits the blast radius when access-control gaps are present. |
| Recommendation — Apply least privilege to reduce exposure if an object or route is misconfigured. | ||
Practitioner Guidance
What to verify: Treat every route that changes state or returns a sensitive object as individually controlled, even if the framework provides a secure default. Verify that unsafe HTML insertion points are rare and reviewed, CSRF coverage is consistent across all browser-authenticated endpoints, and object access is checked on the server at the moment the record is resolved.
Common mistake: Teams often secure the happy path and assume the framework covers the rest. The usual breakpoints are custom middleware bypasses, admin tools, legacy endpoints, and “temporary” exceptions that survive into production.
Practitioner takeaway: Frameworks reduce implementation error, but they do not replace explicit application authorisation, request validation, or output safety. The control lives in how the application uses the framework, not in the framework brand itself.