JSONP

How JSONP Works

JSONP is a legacy cross-origin data retrieval pattern that avoids the same-origin policy for simple GET-style reads by loading a remote script. The server does not return raw JSON; it returns JavaScript that invokes a callback supplied by the requester, so the browser treats the response as executable code rather than as a protected data fetch.

That design explains why JSONP was widely used before modern cross-origin controls became common. It also explains why the technique is inherently trust-based: the client must trust the remote endpoint to return exactly the wrapper it expects, and the browser must trust the script source enough to execute it. If either side behaves unexpectedly, data exposure or script execution issues can follow.

Why JSONP Bypasses Same-Origin Restrictions

JSONP works because browsers historically allow script tags to load code from other origins. A JSONP request is therefore not an XMLHttpRequest-style read blocked by origin policy, but a script inclusion that the browser executes in page context. The callback name becomes part of the request contract, which is why endpoint validation matters as much as the data itself.

This mechanism is useful only for read-only responses. It does not provide a general-purpose cross-origin access model, and it cannot safely substitute for proper cross-origin APIs that use explicit policy controls. When teams rely on JSONP for convenience, they often inherit hidden assumptions about input handling, response shape, and endpoint trust that are easy to overlook during development.

Security Implications and Failure Modes

JSONP is risky because it turns a data response into executable JavaScript. If a callback parameter is not tightly validated, an attacker may influence the wrapper or inject unexpected script logic. If the endpoint reflects sensitive data without strict origin awareness or authorization checks, the browser can expose that data to unintended consumers.

Another common failure mode is treating JSONP like a safe compatibility layer after more secure cross-origin methods are available. That can leave old endpoints exposed long after the original business need has passed. The danger is not just data leakage, but also the broader practice of allowing unaudited third-party script execution in a page that may already hold session context or other sensitive state.

Modern Alternatives and When JSONP Still Appears

Most modern systems should prefer CORS-enabled APIs, same-origin design, or other explicit server-side access patterns rather than JSONP. Those approaches keep data transport and code execution separate, which reduces the chance that a response body becomes an attack surface. They also make authorization, logging, and response handling easier to reason about.

JSONP still appears in older integrations, public data feeds, and compatibility layers where teams have not yet retired legacy browser behavior. In those cases, the right question is not whether JSONP can work, but whether the business need justifies preserving a response pattern that executes remote code in the client. If it does remain in use, treat it as a controlled exception with a clear retirement plan.

Practitioner Guidance

What to watch for: Review any JSONP endpoint as both a data exposure path and a script execution path. Pay close attention to callback parameter handling, origin assumptions, and whether the response can reveal information that should only be available through an authenticated API.

Governance implication: JSONP should be explicitly inventoried in application reviews and deprecation plans, because legacy cross-origin patterns often survive in forgotten endpoints. When a team still depends on it, document the justification, limit the exposed data, and set a path to replace it with a safer cross-origin design.