JSONP vs CORS: warum JSONP heute tot ist

Was JSONP war (und warum es heute tot ist)

JSONP (JSON with Padding) war ein Hack aus der prä-CORS-Ära (vor 2014), um Cross-Origin-Requests aus dem Browser zu machen. Es nutzte die Eigenschaft, dass <script>-Tags keine Same-Origin-Policy unterliegen. Statt einer JSON-Response lieferte der Server einen ausführbaren JavaScript-Aufruf:

// Client
<script src="https://api.example.com/data?callback=handleData"></script>

// Server-Response
handleData({ "result": "ok", "items": [1, 2, 3] });

// Client-Code definiert vorher
function handleData(data) { console.log(data); }

Funktionierte überall (alle Browser, keine Server-Anpassung außer Callback-Wrapping nötig), war aber konzeptionell ein Sicherheits-Albtraum.

Warum CORS JSONP abgelöst hat

CORS (Cross-Origin Resource Sharing) wurde 2014 als W3C-Recommendation finalisiert. Es ermöglicht echte Cross-Origin-XHR/Fetch-Requests, die der Server bewusst freigibt:

// Server-Response-Header
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Authorization, Content-Type

Der Browser holt zuerst per OPTIONS-Preflight die erlaubten Methoden ab und sendet dann den eigentlichen Request, wenn der Server zustimmt.

Die Sicherheits-Probleme von JSONP

1. Keine Same-Origin-Sandbox: Server-Response ist direkt ausführbarer Code. Wenn der Server kompromittiert ist (oder eine Origin böswillig wird), kann er beliebiges JavaScript ausführen.
2. Keine Header-Kontrolle: nur GET-Requests, kein Authorization-Header, keine CSRF-Tokens. Sites, die JSONP für authenticated Endpoints nutzten, waren gegen Cross-Site-Request-Forgery anfällig.
3. Kein Status-Code: JSONP kann keine HTTP-Errors abfangen - wenn der Server 500 liefert, lädt der Script-Tag einfach nichts.
4. Kein Timeout-Handling: <script>-Tags haben keine native Abort-Mechanik.

Heutiger Status

JSONP ist seit ~2018 effektiv tot:

• Alle modernen Frameworks (Angular, React, Vue) nutzen ausschließlich fetch/XHR mit CORS
• jQuery hat JSONP-Support, aber kaum noch genutzt
• Sicherheits-Audits markieren JSONP als High-Risk-Pattern
• CSP (Content Security Policy) verbietet inline-script-Execution, was JSONP zusätzlich erschwert

Wo man trotzdem noch drauf trifft

Manchmal in Legacy-APIs oder bei sehr alten Embeddings:

• Google Maps-API hatte JSONP-Endpoints bis ca. 2020
• Einige Wetterdaten-APIs (z.B. Open-Meteo) bieten optional ?callback= an
• WordPress wp-json-API kennt ?_jsonp=cb-Parameter (deprecated)

Wenn man darauf stößt: nicht JSONP nutzen. Stattdessen einen Server-Proxy aufsetzen, der den Request weitergibt und mit korrekten CORS-Headern antwortet.

CORS-Edge-Cases

Drei Stellen, wo CORS gerne stolpert:

Symptom	Ursache	Fix
"Failed to fetch"	kein Access-Control-Allow-Origin	Server-Config
Preflight schlägt fehl	OPTIONS-Endpoint fehlt	Wildcard-Route
Credentials nicht gesendet	fetch ohne credentials: 'include'	+ ACAllowCredentials: true

Tl;dr

JSONP nicht verwenden. CORS ist der Standard, bei dem Server bewusst entscheidet welche Origins zugreifen dürfen. Wenn ein Drittanbieter nur JSONP bietet - Proxy davorschalten.