# Die API funktioniert mit curl, im Browser aber nicht – ist es wirklich CORS?

Canonical page: https://blame76.com/snippets/javascript/2026-09-17-die-api-funktioniert-mit-curl-im-browser-aber-nicht-ist-es-wirklich-cors/
Category: Snippets
Type: JavaScript
Published: 2026-09-17
Updated: 2026-09-17
Tags: javascript, cors, fetch, http, browser

Der Request funktioniert in curl oder Postman, `fetch()` im Browser scheitert. Das beweist noch nicht, dass die API kaputt ist: Browser setzen zusätzliche Cross-Origin-Regeln durch.

## Erst im Browser unterscheiden

DevTools → Network öffnen und prüfen:

- Gibt es vor dem eigentlichen Request einen `OPTIONS`-Request?
- Welchen Status hat dieser Preflight?
- Welche `Access-Control-Allow-*`-Header kommen zurück?
- Ist der Request tatsächlich cross-origin? Schema, Host **oder Port** können den Origin unterscheiden.

Ein kleiner Test:

```javascript
fetch('https://api.example.test/resource', {
  method: 'GET',
})
  .then(async response => ({
    status: response.status,
    text: await response.text(),
  }))
  .then(console.log)
  .catch(console.error);
```

## Warum curl kein Gegenbeweis ist

CORS ist eine Browser-Sicherheitsregel. Ein Kommandozeilenclient kann eine HTTP-Antwort lesen, die Browser-JavaScript wegen fehlender CORS-Freigabe nicht zugänglich machen darf.

## Nicht blind `Access-Control-Allow-Origin: *`

Bei Credentials/Cookies gelten zusätzliche Regeln, und eine pauschale Freigabe kann das Sicherheitsmodell verändern. Erst festlegen, welche Origins und Methoden wirklich erlaubt sein sollen.

## Andere Fehler nicht mit CORS verwechseln

DNS, TLS, 500er, Redirects oder Mixed Content können ebenfalls im Browser scheitern. Deshalb Network-Request und Console-Fehler gemeinsam lesen – nicht nur die letzte rote Meldung.