Moderne Webanwendungen greifen typischerweise auf APIs zu, die auf verschiedenen Domains, Subdomains oder Ports laufen. Der Browser beschränkt diesen Zugriff durch CORS-Richtlinien. Wenn eine API nicht die korrekten Access-Control-Allow-*-Header zurückgibt, wird die Anfrage vom Browser blockiert — selbst wenn sie serverseitig erfolgreich ausgeführt wird. Das Ergebnis ist eine beschädigte Anwendung für den Benutzer und ein schwer zu diagnostizierender CORS-Fehler für das Team.
In den meisten Organisationen wird dieses Problem an die Anwendungsteams delegiert. Jeder Dienst definiert sein Origin-, Method-, Header-, Credentials- und Max-Age-Verhalten separat in seinen eigenen Framework-Einstellungen. Mit wachsender Anzahl von Diensten wird es unvermeidlich, dass dieselbe CORS-Richtlinie in verschiedenen Anwendungen unterschiedlich geschrieben wird.
Falsche CORS-Einstellungen erzeugen auch Sicherheitsrisiken. Während der Entwicklung werden Wildcard-Origins als schnelle Lösung geöffnet, zu breite Berechtigungen werden zusammen mit Credentials gewährt, oder das Preflight-Verhalten bleibt unvollständig. Wenn solche Einstellungen in die Produktion gelangen, wird die API-Fläche unnötig exponiert.
Der richtige Ansatz ist, CORS-Richtlinien als zentrale Response-/Request-Regel zu verwalten. Die Origin-Allow-List, Credentials, erlaubte Methoden, erlaubte Header und Preflight-Cache sollten alle an einem Ort definiert werden und nicht im Anwendungscode verstreut sein.
Die TR7 CORS-Richtlinienregel liefert dieses Modell: Sie macht Preflight- und Actual-Response-CORS-Header von einer einzigen Aktion aus auf vService- oder Pfadebene verwaltbar.
Die TR7 CORS-Richtlinie bringt Origin-Validierung, Preflight-Verwaltung, Response-Header und bedingte Anwendungslogik unter einer einzigen Regel zusammen.
TR7 kann den eingehenden Origin-Wert gegen eine definierte Allow-List abgleichen. Die Liste kann feste Domains oder flexiblere Regex-basierte Treffer enthalten.
TR7 kann die erforderlichen CORS-Header für OPTIONS-Preflight-Requests generieren. So kann sich die Anwendung nur auf den echten API-Request konzentrieren.
Header wie Access-Control-Allow-Origin, Allow-Methods, Allow-Headers, Allow-Credentials und Max-Age werden über die zentrale Richtlinie hinzugefügt. Die Browser-Kompatibilität wird unabhängig vom Anwendungscode.
Verschiedene API-Flächen auf demselben Gerät können mit unterschiedlichem CORS-Verhalten betrieben werden. Die öffentliche API kann breiter, die Partner-API enger und die interne API mit ihrer eigenen Allow-List verwaltet werden.
Die CORS-Richtlinienregel vereinfacht den API-Veröffentlichungsprozess durch Bereitstellung von Preflight- und Actual-Response-Verwaltung aus einer einzigen Aktion.
Die TR7 CORS-Aktion kann sowohl OPTIONS-Preflight-Requests als auch die echten API-Response-Header unter derselben Richtlinie behandeln. Dies verhindert, dass Anwendungsteams Preflight- und Actual-Response-Verhalten separat kodieren müssen. Die Richtlinie wird einmal definiert und auf den relevanten vService oder Pfad angewendet. Der Betrieb kann das CORS-Verhalten zentral verwalten.
Erlaubte Origin-Werte können in der CORS-Richtlinie explizit definiert werden. Diese Liste kann aus bestimmten Domains, Subdomain-Mustern oder Regex-basierten Treffern bestehen. Vertrauenswürdigen Frontend-Anwendungen wird Zugang gewährt, ohne Wildcards verwenden zu müssen. Der Browser-Zugang wird bereitgestellt, ohne die API-Fläche unnötig unerwünschten Quellen zu exponieren.
Organisationen verwenden häufig Subdomain-Strukturen basierend auf Kunden, Tenants oder Umgebungen. Regex-basierter Origin-Abgleich ermöglicht es, eine kontrollierte Berechtigungsrichtlinie aufzubauen, ohne jede Subdomain einzeln aufzuschreiben. Beispielsweise können Tenant-Frontends unter einem bestimmten Domain-Baum akzeptiert werden. Diese Flexibilität ermöglicht skalierbare CORS-Verwaltung ohne das Öffnen von Wildcards.
Das Access-Control-Allow-Credentials-Verhalten kann zentral ein- und ausgeschaltet werden. Diese Einstellung ist kritisch für Frontends, die mit Cookies oder Authorization-Headern arbeiten. Wenn Credentials aktiviert sind, sollte die Origin-Allow-List eng gehalten werden. TR7 verlagert dieses Verhalten aus verstreuten Anwendungsteam-Einstellungen in einen einzigen Richtlinienpunkt.
Methoden wie GET, POST, PUT, PATCH, DELETE oder OPTIONS können innerhalb der Richtlinie definiert werden. Der Browser akzeptiert während des Preflights nur die erlaubten Methoden. Dies klärt, welche Operationstypen die API der Clientseite zugänglich macht. Sicherheit und Entwicklererfahrung werden aus derselben Liste verwaltet.
Authorization, Content-Type, X-Request-ID oder benutzerdefinierte Anwendungs-Header können in der Allow-List definiert werden. Der Browser prüft während eines Preflight-Requests, ob diese Header verwendet werden können. Fehlende Header-Berechtigungen führen zu Frontend-Fehlern; zu breite Header-Berechtigungen erzeugen unnötige Flächen-Exposition. TR7 verwaltet diese Balance zentral.
Der Access-Control-Max-Age-Wert steuert, wie lange der Browser das Preflight-Ergebnis cacht. Ein angemessener Max-Age-Wert reduziert OPTIONS-Traffic bei häufigen API-Aufrufen. Ein zu kurzer Wert erzeugt unnötigen Preflight-Overhead; ein zu langer Wert bedeutet, dass Richtlinienänderungen möglicherweise spät reflektiert werden. TR7 macht diese Einstellung pro Service-Bedarf konfigurierbar.
Jeder vService kann seine eigene CORS-Richtlinie haben. Die öffentliche API, Partner-API, Admin-API oder interne API können mit unterschiedlichen Origin- und Methodenlisten betrieben werden. Dieses Modell verhindert, dass eine einzelne globale CORS-Einstellung zu breit auf alle APIs angewendet wird. Der Operator richtet Sicherheitsgrenzen pro Service ein.
Verschiedene CORS-Richtlinien können auf verschiedene Pfade innerhalb desselben vService angewendet werden. Beispielsweise kann `/public/api` mit einer breiteren Origin-Liste betrieben werden, während `/admin/api` nur mit einem bestimmten Management-Frontend betrieben wird. Dies trennt die API-Fläche auf Endpoint-Ebene. Es ist nicht notwendig, komplexe CORS-If-Blöcke im Anwendungscode zu schreiben.
Die CORS-Aktion kann als Teil der Traffic-Rules-Engine verwendet werden. CORS-Header können basierend auf Host, Pfad, Header, Methode oder anderen Bedingungen angewendet werden. Dies ermöglicht es, viele verschiedene Veröffentlichungsmodelle auf einem einzigen Gerät zu verwalten. Die CORS-Richtlinie wird zu einer kontextbewussten Traffic-Regel statt einer statischen Einstellung.
Wenn das CORS-Verhalten auf Anwendungs-Frameworks verteilt wird, benötigt jede Sprache und jeder Dienst eine andere Konfigurationslogik. TR7 verlagert dieses Verhalten auf die ADC-Ebene und reduziert die Anwendungsabhängigkeit. Anwendungsteams konzentrieren sich nur auf die API-Geschäftslogik, während der CORS-Standard zentral gepflegt wird. Legacy- und moderne Dienste können unter demselben Richtlinienmodell veröffentlicht werden.
Wenn CORS-Richtlinien innerhalb der zentralen Konfiguration geändert werden, können sie in Audit- und Rollback-Prozesse einbezogen werden. Die Fragen, wer welchen Origin, welche Methode oder welches Credentials-Verhalten geöffnet hat, können nachverfolgt werden. Dies ist besonders wichtig bei Sicherheitsüberprüfungen. Prüfbare CORS-Verwaltung ersetzt verstreute Anwendungseinstellungen.
Die CORS-Richtlinienregel wird zusammen mit Origin-Abgleich, Credentials-Verhalten, Preflight-Response, Max-Age-Balance, Pfad-Geltungsbereich und Audit-Transparenz betrieben.
Der eingehende Origin-Wert kann gegen eine Allow-List oder Regex-Regeln abgeglichen werden. Wenn kein Treffer vorliegt, werden CORS-Header möglicherweise nicht hinzugefügt, oder ein Ablehnungsverhalten wird entsprechend der Richtlinie angewendet. Die Verwendung einer expliziten Liste statt eines Wildcards wird empfohlen.
Wenn Credentials aktiv sind, können Identitätsinformationen wie Cookies und Auth-Header in Cross-Origin-Requests verwendet werden. In diesem Modus ist es wichtig, dass die Origin-Richtlinie eng und klar definiert ist. Credentials zusammen mit einem Wildcard-Origin ist keine sichere Annahme.
OPTIONS-Requests werden vom Browser gesendet, um Methoden- und Header-Berechtigungen zu prüfen. TR7 kann die Preflight-Response zentral verwalten, indem es die erforderlichen Allow-*-Header generiert. Dies reduziert die Belastung des Backend-Dienstes durch unnötige OPTIONS-Last.
Die Preflight-Cache-Dauer erfordert eine Balance zwischen Performance und Richtlinienaktualität. Eine längere Dauer erzeugt weniger OPTIONS-Requests, aber CORS-Änderungen können aufgrund des Browser-Cachings spät spürbar werden. Dieser Wert sollte für kritische APIs sorgfältig gewählt werden.
CORS-Richtlinien können an bestimmte Pfad- oder Host-Bedingungen gebunden werden. Dies ermöglicht es, verschiedenes CORS-Verhalten auf verschiedene API-Flächen innerhalb desselben vService anzuwenden. Admin-Endpoints und öffentliche Endpoints müssen nicht dieselben Berechtigungen teilen.
CORS-Richtlinienänderungen können innerhalb der zentralen Konfiguration und des Audit-Prozesses nachverfolgt werden. Änderungen an der Origin-Liste oder am Credentials-Verhalten sollten als sicherheitsrelevant betrachtet werden. Der Änderungsverlauf hat Wert für Rollback und Compliance.
Wenn eine Frontend-Anwendung auf eine API auf einer anderen Domain zugreift, kann der Browser einen CORS-Fehler erhalten. Das Hinzufügen der korrekten Origin-, Methoden- und Header-Richtlinie über TR7 löst das Problem zentral.
In einer SaaS-Umgebung kann jeder Tenant sein eigenes Frontend auf einer dedizierten Subdomain betreiben. Eine Regex-unterstützte Allow-List akzeptiert den gesamten Tenant-Domain-Baum auf kontrollierte Weise.
Partner-Anwendungen können auf die API nur mit bestimmten Origins und Authorization-Headern zugreifen. Die TR7 CORS-Regel definiert diese Berechtigungen zentral und schließt unnötige Header- und Methodenflächen.
In SSO- oder Föderations-Flows können Cross-Origin-Cookies erforderlich sein. TR7 bringt dieses Verhalten mit dem Credentials-Toggle und einer engen Origin-Liste unter Kontrolle.
Innerhalb desselben vService kann der öffentliche Endpoint mit einer breiteren und der Admin-Endpoint mit einer engeren CORS-Richtlinie betrieben werden. Diese Trennung wird über eine Traffic-Regel angewendet, ohne sie in den Anwendungscode zu schreiben.
Verwalten Sie Preflight, Response-Header, Origin-Allow-List und Credentials-Verhalten aus einer einzigen ADC-Regel. Lassen Sie uns eine Live-Einrichtung auf Ihren eigenen Diensten durchgehen.