CORS korrekt konfigurieren: Security ohne Dev-Blocker

Cross-Origin Resource Sharing (CORS) ist ein essenzielles Sicherheitsfeature moderner Webanwendungen, das den Zugriff von Ressourcen zwischen verschiedenen Domains steuert. Eine fehlerhafte Konfiguration kann entweder legitime Requests blockieren oder Angreifern ungewollt Zugriff gewähren. In diesem Artikel betrachten wir praxisnah, wie CORS korrekt eingerichtet wird, typische Fallstricke vermieden werden und gleichzeitig eine reibungslose Entwicklererfahrung erhalten bleibt.

Grundlagen von CORS

CORS regelt, welche Domains auf Ressourcen einer Webanwendung zugreifen dürfen. Der Browser überprüft anhand von HTTP-Headern, ob ein Request zulässig ist.

Wichtige Header

  • Access-Control-Allow-Origin: Gibt die erlaubten Ursprünge an.
  • Access-Control-Allow-Methods: Legt die zulässigen HTTP-Methoden fest.
  • Access-Control-Allow-Headers: Definiert erlaubte Request-Header.
  • Access-Control-Allow-Credentials: Steuert, ob Cookies oder Auth-Header gesendet werden dürfen.
  • Access-Control-Expose-Headers: Erlaubt dem Browser, bestimmte Response-Header sichtbar zu machen.
  • Access-Control-Max-Age: Gibt die Cache-Dauer für Preflight-Responses an.

Warum CORS notwendig ist

Ohne CORS könnten Webanwendungen von beliebigen Domains Requests absetzen, was XSS oder Datenexfiltration erleichtern würde. CORS stellt sicher, dass nur vertrauenswürdige Ursprünge interagieren dürfen.

Best Practices für sichere CORS-Konfiguration

  • Keine Wildcards mit Credentials: Access-Control-Allow-Origin: * darf nicht zusammen mit Access-Control-Allow-Credentials: true genutzt werden.
  • Whitelist an Domains: Nur explizit erlaubte Domains erhalten Zugriff.
  • Methoden einschränken: Nicht benötigte HTTP-Methoden blockieren.
  • Header limitieren: Nur die notwendigen Header freigeben.
  • Preflight Caching nutzen: Access-Control-Max-Age reduziert unnötige OPTIONS-Requests.

Implementierung in Nginx

Ein gängiger Ansatz ist die Definition von CORS-Headern im Reverse Proxy:

server {
    listen 443 ssl;
    server_name api.example.com;
location / {
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Origin' 'https://frontend.example.com';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type';
add_header 'Access-Control-Allow-Credentials' 'true';
add_header 'Access-Control-Max-Age' 86400;
return 204;
}

add_header 'Access-Control-Allow-Origin' 'https://frontend.example.com';
add_header 'Access-Control-Allow-Credentials' 'true';
proxy_pass http://backend;
}

}

Implementierung in Apache

Apache ermöglicht die CORS-Konfiguration über mod_headers:

<VirtualHost *:443>
    ServerName api.example.com
Header always set Access-Control-Allow-Origin "https://frontend.example.com"
Header always set Access-Control-Allow-Credentials "true"
Header always set Access-Control-Allow-Methods "GET, POST, OPTIONS"
Header always set Access-Control-Allow-Headers "Authorization, Content-Type"

<Location />
Require all granted
</Location>

Typische Fehlerquellen

  • Wildcards mit Credentials aktivieren – führt zu Sicherheitslücken.
  • Preflight OPTIONS Requests werden vom Backend nicht beantwortet – Browser blockiert Requests.
  • Header nicht konsistent gesetzt – unterschiedliche Endpoints liefern unterschiedliche CORS-Header.
  • Fehlende Aktualisierung nach Domainwechsel – neue Frontend-Domain wird nicht berücksichtigt.

Testing und Debugging

Die Überprüfung von CORS kann über Browser-DevTools oder CLI-Tools erfolgen:

curl -i -X OPTIONS https://api.example.com/endpoint 
  -H "Origin: https://frontend.example.com" 
  -H "Access-Control-Request-Method: POST"

Browser-Fehler wie Access to fetch at '...' from origin '...' has been blocked by CORS policy deuten auf Fehlkonfigurationen hin.

Erweiterte Patterns

In komplexen Architekturen kann dynamische CORS-Whitelist-Logik sinnvoll sein:

  • Whitelist in Redis oder Datenbank speichern
  • Lua oder Module für dynamisches Setzen von Access-Control-Allow-Origin in Nginx
  • Logging von CORS-Fehlern zur Identifikation nicht autorisierter Zugriffe

Fazit für Dev- und Prod-Umgebungen

Eine saubere CORS-Konfiguration verhindert Sicherheitslücken, während Entwickler weiterhin flexibel auf APIs zugreifen können. Die Kombination aus Proxy-Level Header-Setzung, klar definierten Whitelists und Preflight-Caching bietet eine robuste und performante Lösung für produktive Webstacks.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

  • Professionelle Konfiguration von Routern und Switches

  • Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

  • Erstellung von Topologien und Simulationen in Cisco Packet Tracer

  • Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

  • Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

  • Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

  • Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

  • Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.

Related Articles