Skip to content

CORS Origins

Moderne Browser blocken Cross-Origin-Requests standardmaessig. Laeuft dein Frontend auf einer anderen Domain als die CMS-API — z.B. eine Nuxt-Site auf example.com, die api.example.com aufruft, oder ein Entwicklungs-Server auf localhost:3000 — musst du diese Origin im CMS explizit freigeben.

Die Origin-Liste liegt bei den API-Schluesseln. Oeffne Einstellungen → API-Schlüssel und wechsel auf den Origins-Tab.

Origin-Liste mit Origin hinzufuegen und Loeschen

So sieht eine Origin aus

Eine Origin ist Schema + Host + optionaler Port — ohne Pfad, ohne abschliessenden Slash:

text
https://example.com
https://www.example.com
http://localhost:3000

Das Protokoll zaehlt: http:// und https:// sind zwei verschiedene Origins. Ebenso www vs. Apex-Domain.

Der implizite Eigen-Eintrag

Das CMS erlaubt die eigene Domain (own_domain) automatisch. Fuer die Admin-UI brauchst du keinen Eintrag. Eintraege sind zusaetzlich fuer Frontends auf anderen Hosts.

1. Origin hinzufuegen

Klick oben rechts Origin hinzufügen. Das Modal fragt nach:

FeldZweck
OriginVolle URL wie oben.
AktivHaken entfernen, um die Origin ohne Loeschen zu deaktivieren.
Origin-hinzufuegen-Modal mit URL-Feld

Klick Speichern. Der Browser akzeptiert ab sofort Responses der CMS-API, wenn er von dieser Origin aus aufruft.

Staging, Vorschau, Entwicklung

Halt getrennte Eintraege fuer Staging (https://staging.example.com), Vorschau (https://preview-123.vercel.app) und lokale Entwicklung (http://localhost:3000). Aktiv toggeln engt die Allowlist vor einem Live-Release ein.

2. Origin loeschen

Klick auf das Muell-Icon Löschen. Cross-Origin-Requests von dieser URL scheitern beim naechsten Aufruf mit einem Browser-CORS-Fehler. Der Server antwortet zwar weiterhin — er liefert nur keinen Access-Control-Allow-Origin-Header mehr, und der Browser lehnt die Antwort ab.

Was CORS tut und was nicht

CORS ist ein Browser-Schutz, kein Server-Schutz. Das Entfernen einer Origin verhindert keinen Server-zu-Server-Aufruf (z.B. curl). Dafuer brauchst du:

  • Einen API-Schluessel mit konfigurierten Rechten, und/oder
  • Authentifizierte Backend-Sessions, und/oder
  • Den Rate-Limiter (429 nach Ausschoepfen des Pro-IP-Budgets).

CORS wirkt nur auf Browser-Fetches mit credentials: 'include' oder ueber eine oeffentlich-privat-Grenze.

Platzhalter

Platzhalter-Origins (*) werden fuer Requests mit Anmeldedaten standardmaessig nicht unterstuetzt — die gleichen Browser-Standards, die CORS definieren, verbieten die Kombination. Die CMS-API nutzt Cookies fuer Backend-Sessions, deshalb muss jede Origin explizit sein.

Haeufige Fehler

Browser-Konsole meldet "CORS error", aber curl funktioniert. Erwartet — CORS ist nur Browser-Sache. Fueg die Origin hinzu.

Cross-Origin-Request feuert einen OPTIONS-Preflight, der 200 liefert, aber der eigentliche Request scheitert. Pruef, ob die Origin im Request exakt dem Eintrag entspricht (kein abschliessender Slash, gleiches Protokoll, gleicher Port).

Ein Request von https://foo.com geht, https://www.foo.com nicht. Subdomains sind eigene Origins. Fueg jede benutzte hinzu.

Siehe auch

  • API-Schluessel — fuer Nicht-Browser-Aufrufer.
  • Webhooks — ausgehende Aufrufe aus dem CMS (kein CORS beteiligt).