XHR

XMLHttpRequest, often shortened to XHR, is a browser mechanism used to send asynchronous requests from a web page to an API. In single-page applications, XHR traffic carries much of the application’s business logic, so security testing must inspect it to understand the true attack surface and authorisation behaviour.

Expanded Definition

XHR, short for XMLHttpRequest, is the browser-side interface that lets web pages send asynchronous requests without a full page reload. In security work, XHR matters because it often exposes the real application workflow behind a polished user interface, including API calls, hidden parameters, object identifiers, and authorisation decisions that are not obvious from static page content. For NHI Management Group, the security relevance is practical: XHR traffic can reveal where session handling, token use, and backend trust boundaries are weakest.

XHR is sometimes treated as a legacy term because modern applications also use fetch(), GraphQL clients, and other request abstractions. That does not reduce its value as a testing concept. Security teams still use “XHR” as shorthand for browser-originated asynchronous traffic that must be inspected for access control flaws, data exposure, and state-changing requests. Definitions vary slightly across tooling vendors, but the core meaning remains the same: browser-initiated network requests that can be intercepted, replayed, and manipulated. For broader governance language, the NIST Cybersecurity Framework 2.0 helps situate this traffic within asset protection and secure application design.

The most common misapplication is treating XHR as only a front-end performance detail, which occurs when testers review page rendering but ignore the actual API calls carrying sensitive business actions.

Examples and Use Cases

Implementing XHR-aware testing rigorously often adds analysis overhead, requiring teams to balance faster UI validation against the cost of tracing each request back to its server-side effect.

• A single-page banking portal uses XHR to submit beneficiary changes, and testers inspect the request body to confirm that server-side authorisation cannot be bypassed by editing object identifiers.
• An internal admin console loads user records through XHR, making it possible to identify overexposed fields such as email addresses, role data, or reset tokens that should never reach the browser.
• A SaaS application performs cart updates through XHR, and a security review checks whether quantity, price, and discount values are validated server-side rather than trusted from the client.
• An API-backed dashboard issues XHR calls with bearer tokens, and testers verify whether token scope, session expiry, and CSRF protections are enforced consistently.
• During an application review, engineers compare visible actions to the XHR stream to discover hidden endpoints that are not linked in the UI but remain reachable if the browser request is replayed.

For testing methodology, browser traffic inspection is commonly paired with guidance from the OWASP Cheat Sheet Series, especially where client-controlled requests can influence privileged backend behaviour. The same logic applies when reviewing mobile or hybrid interfaces that mimic browser-style asynchronous calls.

Why It Matters for Security Teams

XHR is important because many modern application flaws are not visible from the rendered page. Access control failures, mass assignment, broken object-level authorisation, and unsafe assumptions about client-side validation often appear only when the underlying requests are examined. Security teams that understand XHR can map user actions to actual API transactions, which is essential for finding where the application trusts the browser too much. That is especially relevant in environments using identity-aware sessions, where a valid login does not automatically mean each asynchronous request is properly authorised.

XHR also helps teams distinguish presentation from enforcement. A page may hide a button, but if the XHR endpoint remains callable, the control is cosmetic rather than security-relevant. This becomes even more important in applications that rely on tokens, temporary credentials, or delegated access, because browser requests may carry privileged context that can be replayed, modified, or abused if poorly protected. Teams assessing web applications in line with the OWASP Application Security Verification Standard often use XHR inspection to validate whether the server actually enforces the intended access model.

Organisations typically encounter XHR as a security priority only after an API abuse case, at which point request inspection becomes operationally unavoidable to explain how the browser was able to reach the affected backend function.