CORS für APIs

IRC-Mania Die Seite rund um Sicherheit und Programmierung

Internet, Sicherheit , Internet Relay Chat

Gesponsert

CORS ermöglicht kontrollierten Zugriff auf Ressourcen über Domaingrenzen hinweg, muss aber korrekt konfiguriert werden, um Sicherheitsrisiken zu vermeiden.

Kompakte Beschreibung

CORS steht für Cross-Origin Resource Sharing und ist ein Mechanismus, der es Browsern erlaubt, Ressourcen von einer anderen Domain anzufordern, als die, von der die aktuelle Webseite geladen wurde. Standardmäßig blockiert der Browser solche Cross-Origin-Anfragen, um vor unbefugtem Datenzugriff zu schützen. CORS ermöglicht es Servern, explizit erlaubte Ursprünge, Methoden und Header anzugeben. Eine korrekte CORS-Konfiguration ist wichtig für APIs, die von Browser-Anwendungen genutzt werden. Gleichzeitig ist eine zu lockere Konfiguration ein Sicherheitsrisiko, weil sie Cross-Origin-Angriffe ermöglicht. Wichtige Konzepte sind der Origin Header, Preflight-Requests, Access-Control-Header und die Unterscheidung zwischen einfachen und komplexen Anfragen.

Wichtige Komponenten

Same-Origin Policy

Die Same-Origin Policy ist ein grundlegender Sicherheitsmechanismus im Browser. Sie verhindert, dass eine Webseite von einer Domain auf Daten einer anderen Domain zugreift. Ursprung wird durch Protokoll, Domain und Port definiert. Unterschiedliche Subdomains oder Ports gelten als unterschiedliche Ursprünge.

Origin Header

Der Browser sendet bei Cross-Origin-Anfragen einen Origin Header, der die Ursprungsdomain angibt. Der Server entscheidet anhand dieses Headers, ob die Anfrage erlaubt ist. Der Server antwortet mit Access-Control-Allow-Origin und weiteren CORS-Headern.

Access-Control-Allow-Origin

Dieser Header gibt an, welche Ursprünge auf die Ressource zugreifen dürfen. Er kann eine konkrete Domain wie https://app.example.com oder * für alle Domains enthalten. Wildcards sollten für APIs mit Authentifizierung oder sensiblen Daten vermieden werden.

Access-Control-Allow-Methods

Dieser Header listet die erlaubten HTTP-Methoden für Cross-Origin-Anfragen auf, wie GET, POST, PUT, DELETE. Nur die explizit erlaubten Methoden dürfen vom Browser verwendet werden.

Access-Control-Allow-Headers

Dieser Header gibt an, welche zusätzlichen Header der Client in der Anfrage senden darf. Standard-Header wie Content-Type, Accept oder Authorization müssen gegebenenfalls explizit erlaubt werden, wenn sie benutzerdefiniert sind.

Access-Control-Allow-Credentials

Dieser Header erlaubt es, dass Cookies, HTTP-Authentifizierung oder Client-Zertifikate bei Cross-Origin-Anfragen übertragen werden. Wenn er auf true gesetzt ist, darf Access-Control-Allow-Origin nicht * sein, sondern muss eine konkrete Domain angeben.

Preflight Request

Bei komplexen Cross-Origin-Anfragen sendet der Browser zunächst eine OPTIONS-Anfrage, das Preflight. Der Server antwortet mit den erlaubten Methoden, Headern und Ursprüngen. Erst danach sendet der Browser die eigentliche Anfrage. Preflight-Anfragen werden für Methoden wie PUT, DELETE oder bei benutzerdefinierten Headern ausgelöst.

Einfache und komplexe Anfragen

Einfache Anfragen nutzen GET, HEAD oder POST mit bestimmten Content-Types und Standard-Headern. Sie erfordern kein Preflight. Komplexe Anfragen nutzen andere Methoden, benutzerdefinierte Header oder Content-Types und lösen ein Preflight aus.

CORS und Sicherheitsrisiken

Falsche CORS-Konfigurationen können zu unbefugtem Zugriff führen. Besonders gefährlich sind Access-Control-Allow-Origin: * bei APIs mit Credentials, dynamische Spiegelung des Origin Headers ohne Validierung und das Erlauben unsicherer Methoden. Angreifer können solche Fehler ausnutzen, um Daten im Browser zu stehlen.

CORS in der API-Konfiguration

CORS wird meist im API-Gateway, Webserver oder im Anwendungscode konfiguriert. In Node.js wird häufig das cors Middleware-Paket genutzt, in Spring Boot gibt es @CrossOrigin, in ASP.NET Core UseCors. Unabhängig von der Technik sollte die Konfiguration restriktiv und explizit sein.

Debugging von CORS

CORS-Fehler im Browser zeigen oft keine detaillierten Informationen an. Die Browser-Entwicklertools und Netzwerk-Logs helfen, Preflight- und Hauptanfragen zu untersuchen. Serverseitige Logs sollten die Origin Header und Antworten protokollieren.

Praxisbeispiel

Eine Webanwendung unter https://app.example.com greift auf eine API unter https://api.example.com zu. Die API muss CORS für diesen Ursprung erlauben.

Browser sendet die Anfrage:

GET /api/v1/profile
Host: api.example.com
Origin: https://app.example.com
Authorization: Bearer TOKEN

Server antwortet mit CORS-Headern:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization

{
  "name": "Max Mustermann",
  "email": "max@example.com"
}

Bei einer PUT-Anfrage sendet der Browser zuerst ein Preflight:

OPTIONS /api/v1/profile
Host: api.example.com
Origin: https://app.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type, Authorization

Server antwortet auf das Preflight:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400

Erst danach sendet der Browser die eigentliche PUT-Anfrage. So stellt CORS sicher, dass nur autorisierte Ursprünge auf die API zugreifen.

IRC-Security.de

Cybersecurity Artikel und Tutorials

FAQ: CORS für APIs

Quellen

1. https://developer.mozilla.org/docs/Web/HTTP/CORS
2. https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/11-Client-side_Testing/07-Testing_Cross_Origin_Resource_Sharing
3. https://fetch.spec.whatwg.org/#cors-protocol

Buchempfehlungen zur Web-Sicherheit

Wenn Du Dich weiter mit CORS, Web-Sicherheit und API-Sicherheit beschäftigen möchtest, empfehlen wir Dir die folgenden Bücher:

Premium VPS Hosting

Schnelle und sichere VPS Server

Gesponsert