Prevent it by ensuring sensitive JSON is only returned to authenticated callers and cannot be read through cross-site script inclusion. Use anti-CSRF controls, avoid exposing secrets in array responses that can be captured by older browser techniques, and set response headers and content types so the browser does not treat the data as executable script.
How JSON hijacking happens
JSON hijacking is a browser-side data theft problem, not a server-side parsing bug. The danger appears when sensitive JSON can be fetched through a cross-origin script tag or other legacy inclusion path, then interpreted in a way that exposes the response body to an attacker-controlled page. That risk is highest when the response is readable without a user-specific check or when the payload shape is easy to steal.
Older browser techniques are the historical reason this issue still matters in some codebases. If an endpoint returns a bare array or other script-friendly response, an attacker may be able to abuse the browser’s handling of executable content rather than breaking the JSON itself. That is why response shape and delivery context matter as much as the data content.
For teams auditing exposure, this is the same class of problem that makes Web Application Attacks Guide useful: the weakness is rooted in how browsers, origins, and response handling interact, not just in the API route itself.
Mitigations that actually reduce exposure
The most effective mitigation is to ensure sensitive JSON is only returned to callers that are already authenticated and authorised to receive it. That means treating the endpoint like a protected data source, not a public document. If the browser cannot fetch the response in a cross-site context, the hijack path collapses.
Use anti-CSRF controls where the request is stateful or user-specific, and do not rely on obscurity or same-origin assumptions alone. Setting the correct content type, disabling script execution for the response, and avoiding JSONP-style exposure all help keep the browser from treating the payload as executable script.
Response design matters too. Avoid exposing secrets in top-level array responses, especially if legacy clients are in scope. Wrapping the payload in an object, requiring a non-simple request pattern, and checking origin or referer where appropriate can all reduce the chance that another site can read the data through script inclusion.
What to change in code, headers, and client behaviour
Harden the endpoint so the browser receives unambiguous non-executable JSON. Set a correct JSON content type, add defensive response headers, and ensure the endpoint is not available to anonymous cross-site requests. If the application still supports older browsers or legacy integrations, test those paths explicitly because the risk is often tied to compatibility behaviour that modern teams no longer exercise.
Look at the full request flow, not just the controller. Session cookies, cache behaviour, content sniffing, and whether the response can be reused by intermediaries all affect whether a browser can be tricked into exposing the body. A mitigation is only real if the browser and any shared infrastructure consistently enforce it.
Risk and Threat Considerations
JSON hijacking matters most when an endpoint returns user-specific data that is valuable enough to steal but convenient enough to expose through a browser. The risk is confidentiality loss through a trust boundary mistake: the application assumes the browser will only deliver the response to the intended origin, while the attacker exploits inclusion mechanics to read it elsewhere.
Failure mechanism: A cross-site script inclusion path, combined with permissive response shape or weak browser handling, lets attacker-controlled code infer or capture the JSON body without breaking server authentication directly.
Impact: Sensitive profile data, account details, tokens, or other private records can leak to an external site, and the exposure may persist until the endpoint, response format, or client-side assumptions are corrected.
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 CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OIDC | JSON hijacking is prevented by strong browser-facing auth flows and protected API access. |
| V9 — Self-contained Tokens | Token-based access can reduce exposure when JSON endpoints must be guarded per request. | |
| V12 — Secure Communication | Response handling and headers are central to preventing script-based cross-site data exposure. | |
| Recommendation — Require authenticated access patterns that prevent cross-site data reads. Use token-based controls that bind access to the intended caller. Enforce secure response handling and transport settings that block script interpretation. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Sensitive JSON should be limited to authenticated, authorised accounts only. |
| AC-6 — Least Privilege | Endpoints should expose only the minimum data needed to reduce hijack impact. | |
| SC-18 — Mobile Code | JSON hijacking exploits browser treatment of data as executable script. | |
| Recommendation — Restrict sensitive JSON access to approved accounts and sessions. Limit each response to the minimum data required by the caller. Prevent browsers from executing data responses as script. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Access restrictions are the primary mitigation for sensitive JSON exposure. |
| CIS-16 — Application Software Security | Secure web application response handling is needed to prevent script-based data theft. | |
| Recommendation — Restrict access to sensitive JSON endpoints to authorised users only. Harden application responses so JSON cannot be treated as executable content. | ||
Practitioner Guidance
What to verify: Confirm whether the endpoint is reachable cross-origin, whether anonymous callers can trigger it, and whether any response contains sensitive data in an array or otherwise script-friendly form. Test modern and legacy browser behaviour separately, because the dangerous path may only exist in older handling models.
Decision rule: If the response carries sensitive user data, require authenticated access and make the response non-executable by design before you rely on headers alone. If you cannot guarantee that for every supported client, treat the endpoint as high risk and redesign the payload shape and delivery pattern.
Practitioner takeaway: The key control is not one header in isolation, it is making sure the browser never has a chance to treat private JSON as cross-site readable script.