1. Was ist CORS
Was ist CORS (Cross Origin Resource Sharing)¶
- Ermöglicht kontrollierten Zugriff auf Ressourcen außerhalb einer bestimmten Domain
- Erweitert und flexibilisiert die Same-Origin-Policy (SOP)
- Birgt Potenzial für Cross-Domain Angriffe, wenn die Richtlinien falsch konfiguriert oder schlecht umgesetzt sind
Same-Origin Policy¶
Wurde vor vielen Jahren eingeführt um bösartige Interaktionen zwischen verschiedenen Domains zu verhindern
Die Regel erlaubt es einer Domain in der Regel, Anfragen an andere Domains zu senden,
aber nicht, die Antworten darauf zu lesen oder zu verarbeiten.
Lockerung der Same-Origin Policy¶
Weil die SOP sehr restriktiv ist und moderne Websites mit Subdomains oder Drittanbieter interagieren müssen, wurden in der Zeit verschiedene Mechanismen entwickelt um diese Beschränkung zu lockern - Eine davon ist CORS - Cross-Origin Resource Sharing
Wie funktioniert das CORS-Protokoll¶
- Mit einer Reihe von HTTP-Headern um festzulegen
- welche Ursprünge(Websites/Domains) als vertrauenswürdig gelten
- welche Zugriffsrechte sie haben - z. B. ob authentifizierte Anfragen erlaubt sind.
- Diese Infos werden in einem Header Austausch zwischen dem Browser und der externen Cross Origin Website übermittelt.
Wichtige CORS-Header + Beispiele¶
1. Access-Control-Allow-Origin¶
Legt fest, welche Domains Zugriff auf die Ressource haben.
| Beispiel | Bedeutung |
|---|---|
Access-Control-Allow-Origin: * |
Jede Domain darf zugreifen (unsicher, aber oft bei öffentlichen APIs). |
Access-Control-Allow-Origin: https://meineapp.de |
Nur Anfragen von dieser Domain sind erlaubt. |
Access-Control-Allow-Origin: null |
Wird bei lokalen Dateien oder Sandbox-Umgebungen genutzt. |
Sicherheits-Tipp:
Wenn du Cookies oder Tokens mitschicken willst, niemals * verwenden — das blockt der Browser automatisch.
2. Access-Control-Allow-Methods¶
Definiert, welche HTTP-Methoden erlaubt sind.
| Beispiel | Bedeutung |
|---|---|
Access-Control-Allow-Methods: GET, POST |
Nur GET- und POST-Anfragen sind erlaubt. |
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS |
Volle API-Unterstützung (REST-Stil). |
Wird beim sogenannten Preflight-Request (OPTIONS-Anfrage) zurückgegeben, bevor der Browser die eigentliche Anfrage sendet.
3. Access-Control-Allow-Headers¶
Legt fest, welche benutzerdefinierten Header vom Client gesendet werden dürfen.
| Beispiel | Bedeutung |
|---|---|
Access-Control-Allow-Headers: Content-Type, Authorization |
Erlaubt z. B. JSON-Daten (Content-Type) und Token (Authorization). |
Wenn du im Client eigene Header setzt (z. B. JWT im Authorization-Header), muss der Server diese hier auflisten.
4. Access-Control-Allow-Credentials¶
Erlaubt oder verbietet das Mitsenden von Cookies, Tokens oder HTTP-Authentifizierungsdaten.
| Beispiel | Bedeutung |
|---|---|
Access-Control-Allow-Credentials: true |
Browser darf Cookies oder Auth-Daten mitsenden. |
| (Standard ist „false“) | Keine Anmeldeinformationen erlaubt. |
Wichtig: Wenn du Credentials: true erlaubst, darfst du nicht Access-Control-Allow-Origin: * verwenden, sondern eine feste Domain angeben.
5. Access-Control-Max-Age¶
Wie lange der Browser das Preflight-Ergebnis cachen darf.
| Beispiel | Bedeutung |
|---|---|
Access-Control-Max-Age: 600 |
Browser darf das Ergebnis 10 Minuten (600 Sekunden) speichern. |
Das spart Zeit, weil der Browser nicht bei jeder Anfrage erneut nachfragen muss.
6. (Client-seitig) Origin¶
Wird vom Browser automatisch gesendet, um dem Server mitzuteilen, von welcher Domain die Anfrage kommt.
| Beispiel | Bedeutung |
|---|---|
Origin: https://meineapp.de |
Anfrage kommt von dieser Domain. Der Server prüft, ob sie erlaubt ist. |
| ## Beispiel-Austausch (Preflight + Response) |
Browser sendet:¶
OPTIONS /api/data HTTP/1.1
Origin: https://meineapp.de
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization
Server antwortet:¶
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://meineapp.de
Access-Control-Allow-Methods: POST, GET
Access-Control-Allow-Headers: Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 600
Wenn sie passt, wird danach die eigentliche POST-Anfrage gesendet.
[!note] Einfach gesagt Auf dem API Server liegt die "Gästeliste" wer denn auf die API und wo genau zugreifen kann und der Header schickt einfach nur seinen "Ausweis" mit und der API Server checkt das.
[!danger] Achtung CORS nur Browser bedingt geschützt. Wird die Seite mit z. B. Burp Suit aufgerufen ist es unsicher. Deshalb ist es wichtig, dass es mit Tokens kombiniert wird.