Cross-Origin Resource Sharing (CORS)
CORS ist ein browserseitiges Sicherheits- und Integrationsmodell, das regelt, welche fremden Ursprünge auf Webressourcen zugreifen dürfen.
Klassifikation
- KomplexitätMittel
- AuswirkungTechnisch
- EntscheidungstypArchitektur
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Übermäßig großzügige Allow-Origin-* Einstellungen führen zu Datenexposition.
- Falsche Handling von Credentials ermöglicht Cross-Site-Leaks.
- Vertrauen auf CORS allein ersetzt keine serverseitige Authentifizierung.
- Vermeide '*' für Access-Control-Allow-Origin in Produktivsystemen.
- Whiteliste expliziter Origins und aktualisiere sie automatisiert.
- Trenne Policies für öffentliche und credentialed Endpunkte.
I/O & Ressourcen
- Liste erwarteter Ursprünge
- Server- oder API-Konfigurationszugriff
- Security- und Compliance-Anforderungen
- Definierte Access-Control-Header
- Dokumentierte CORS-Policy
- Monitoring für blockierte Anfragen
Beschreibung
Cross-Origin Resource Sharing (CORS) ist ein browserseitiges Sicherheits- und Integrationsmodell, das regelt, welche fremden Ursprünge auf Ressourcen einer Webanwendung zugreifen dürfen. Es basiert auf standardisierten HTTP-Headern und definiert, wie Browser Anfragen erlauben oder blockieren. Die korrekte Konfiguration von Allow-Origin- und Credentials-Headern beeinflusst Sicherheit und Kompatibilität.
✔Vorteile
- Ermöglicht kontrollierte Integrationen zwischen Domains.
- Reduziert Fehlkonfigurationen durch standardisierte Header.
- Verbessert Sicherheit gegenüber uneingeschränktem Cross-Origin-Zugriff.
✖Limitationen
- Nur wirksam in Browsern; Server-zu-Server-Kommunikation ist davon unberührt.
- Komplexe Credential-Szenarien erfordern präzise Konfiguration.
- Fehlkonfiguration kann legitime Integrationen blockieren.
Trade-offs
Metriken
- Anzahl blockierter Cross-Origin-Anfragen
Zählt Requests, die vom Browser wegen fehlender CORS-Header blockiert wurden.
- Konfigurationsfehler pro Release
Misst fehlerhafte CORS-Setups, die zu Supporttickets führten.
- Anzahl erlaubter Origins
Anzahl der in Whitelists gepflegten Origins, Indikator für Verwaltungsaufwand.
Beispiele & Implementierungen
Konfiguration einer REST-API für SPA-Zugriff
Beispielhafte Serverkonfiguration, die Access-Control-Allow-Origin auf die SPA-Domain setzt und notwendige Methoden erlaubt.
Einbindung eines Payment-Widgets mit CORS
Schrittweise Integration eines Zahlungswidgets inklusive whitelisting der Widget-Origin und der Handhabung von Credentials.
Fehleranalyse: CORS-Fehlermeldungen im Browser
Typische Ursachen und Debugging-Schritte für Blockierungen durch die Same-Origin-Policy und fehlende Header.
Implementierungsschritte
Analyse: Identifiziere benötigte Origins und Methoden.
Konfiguration: Setze Access-Control-Header auf dem Server oder API-Gateway.
Test: Überprüfe Browser-Verhalten und credentialed Szenarien.
Monitoring: Überwache blockierte Anfragen und Supportfälle.
⚠️ Technische Schulden & Engpässe
Tech Debt
- Hardcodierte Origin-Listen in Konfigurationsdateien.
- Unzureichende Tests für Preflight- und credentialed Szenarien.
- Kein Monitoring für blockierte Cross-Origin-Anfragen.
Bekannte Engpässe
Beispiele für Missbrauch
- Setzen von Allow-Origin: * zusammen mit Allow-Credentials: true.
- Ignorieren von Preflight-Anfragen bei komplexen Requests.
- Vertrauen auf CORS als einzige Schutzmaßnahme für sensible APIs.
Typische Fallen
- Browser-Fehlermeldungen können irreführend sein und fehlen oft serverseitige Hinweise.
- Fehlerhafte Kombinationen von Credentials-Headern blockieren legitime Zugriffe.
- Proxy- oder CDN-Header-Overwrite kann Policy ungewollt ändern.
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Browser-Implementierungen können leicht variieren.
- • Server muss kontrollierten Access-Control-Header setzen können.
- • Bei Credentials ist Access-Control-Allow-Origin kein Wildcard.