Find out whether a browser would let your code read an API response, and exactly which check blocks it. Real preflight and request diagnostics, not a header dump.
Ein Origin pro Zeile, bis zu zehn. Nützlich, um zu prüfen, ob lokale Umgebung, Staging und Produktion alle auf der Allowlist stehen. Die Ergebnisse erscheinen als Tabelle im Tab Header.
Diese Anfragen werden von POLPROG Servern an den von Ihnen genannten Endpunkt gesendet, weil ein Browser diese Diagnose nicht an sich selbst durchführen kann: CORS ist genau das, was ihn daran hindern würde. Kein Cookie von Ihnen wird weitergeleitet, es wird nie ein Request-Body gesendet, Response-Bodies werden verworfen, und nichts wird gespeichert, sobald der Bericht bei Ihnen ist.
Eine Regel des Browsers, keine des Servers. Wenn JavaScript auf einem Origin eine Ressource auf einem anderen anfragt, sendet der Browser die Anfrage, weigert sich aber, die Antwort an Ihren Code zu übergeben, solange der Server nicht in seinen Response-Headern erklärt, dass der anfragende Origin sie lesen darf. Cross-Origin Resource Sharing ist der Satz von Headern, mit denen das erklärt wird.
Wenn eine Anfrage in curl, Postman, Insomnia oder von Ihrem eigenen Backend aus funktioniert, sagt das nichts darüber aus, ob JavaScript im Browser sie lesen kann. Diese Clients wenden überhaupt keine CORS-Regeln an. Der Server verhält sich meist in beiden Fällen identisch; der Unterschied liegt allein darin, was der Aufrufer mit der Antwort macht.
Für alles außer den einfachsten Anfragen sendet der Browser zuerst eine OPTIONS-Anfrage und fragt damit, ob die eigentliche erlaubt ist. Sie trägt Origin, Access-Control-Request-Method und, falls nötig, Access-Control-Request-Headers. Erlaubt die Antwort die Anfrage nicht, wird die eigentliche nie gesendet, der Endpunkt sieht sie also nie und Ihre Server-Logs zeigen nichts.
Eine Anfrage ist nur dann einfach, wenn ihre Methode GET, HEAD oder POST ist und jeder Header, den sie setzt, auf der CORS-Safelist steht: Accept, Accept-Language, Content-Language, Content-Type und Range. Der Wert zählt ebenfalls. Content-Type bleibt nur für application/x-www-form-urlencoded, multipart/form-data und text/plain auf der Safelist.
Es steht nicht auf der Liste der drei Content-Type-Werte, die auf der Safelist stehen. Das ist der ganze Grund. Ein POST mit einem JSON-Body ist eine Anfrage mit Preflight, und deshalb erzeugt das Hinzufügen einer JSON-API zu einer bestehenden Seite plötzlich eine OPTIONS-Anfrage, die niemand geschrieben hat, sowie Fehler aus einer Route, die nur POST behandelt.
Entweder ein einzelner Origin oder *. Nie eine Liste, nie ein Wert mit Pfad, nie eine Wildcard innerhalb eines Hostnamens. Der Vergleich mit dem anfragenden Origin ist exakt, ein abschließender Schrägstrich, ein ausgeschriebener Standardport oder http, wo die Anfrage https verwendet hat, führen deshalb alle zum Fehlschlag, obwohl sie für einen Menschen identisch aussehen.
Erforderlich, wenn die Anfrage Cookies oder HTTP-Authentifizierung sendet. Der einzige akzeptierte Wert ist die exakte kleingeschriebene Zeichenkette true. Eine Anfrage mit Credentials lässt sich außerdem nicht durch Access-Control-Allow-Origin: * erfüllen, und für dieselbe Anfrage hört ein Sternchen in Allow-Methods, Allow-Headers oder Expose-Headers auf, eine Wildcard zu sein, und wird zu einem wörtlichen Namen.
Wählt der Server den Wert für Allow-Origin aus der eingehenden Anfrage, hängt die Antwort vom Origin-Header ab, und jeder gemeinsam genutzte Cache muss davon erfahren. Ohne Vary: Origin kann ein CDN oder ein Reverse Proxy eine Antwort speichern, die einen Origin nennt, und sie an einen anderen ausliefern, sodass Anfragen aus Gründen fehlschlagen, die in der Anwendung nie auftauchen.
Eine Cross-Origin-Antwort gibt einem Skript nur sieben Header frei: Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified und Pragma. Alles andere, einschließlich Ihrer eigenen Header mit dem Präfix X- und Location, liest sich als null, solange es nicht in Access-Control-Expose-Headers genannt wird. Dieser Header betrifft die Antwort und hat nichts mit Allow-Headers zu tun, das die Anfrage betrifft.
Es entscheidet, welche Origins eine Antwort in einem Browser lesen dürfen. Es entscheidet nicht, wer einen Endpunkt aufrufen darf, es vergibt keine Berechtigungen, und es verhindert keine Cross-Site Request Forgery: Ein CSRF-Angriff muss die Antwort nicht lesen, eine strenge CORS-Policy lässt ihn also unberührt. Behalten Sie Authentifizierung, Autorisierung und CSRF-Token genau so bei, wie sie waren.
Jedes Urteil hier stammt aus einem tatsächlichen Austausch mit dem von Ihnen genannten Endpunkt, bewertet nach den Regeln aus dem Fetch standard, die ein Browser anwendet. Es beschreibt den Endpunkt so, wie er der POLPROG Infrastruktur in diesem Moment geantwortet hat: Ein Server, der seine Antwort nach Netzwerk, nach Region oder nach Authentifizierung variiert, kann Ihrem Browser anders antworten. Die Zeiten werden von unserer Infrastruktur aus gemessen und sind keine Messung im Browser. Der Test der eigentlichen Anfrage ist für Methoden, die Daten verändern können, standardmäßig ausgeschaltet, und es wird nie ein Request-Body gesendet.
Weil CORS von Browsern durchgesetzt wird und von sonst nichts. Postman, curl, Insomnia und Ihr eigenes Backend wenden überhaupt keine CORS-Regeln an, sie erhalten die Antwort also unabhängig davon, welche Header sie trägt. Der Server verhält sich meist in beiden Fällen identisch. Der Unterschied liegt allein darin, was der Aufrufer mit der Antwort macht, und ein Browser weigert sich, sie an Ihr JavaScript zu übergeben, solange die Antwort nicht sagt, dass dieser Origin sie lesen darf.
Eine OPTIONS-Anfrage, die der Browser vor der eigentlichen sendet, um zu fragen, ob die eigentliche erlaubt ist. Sie trägt Origin, Access-Control-Request-Method und, falls nötig, Access-Control-Request-Headers. Erlaubt die Antwort die Anfrage nicht, wird die eigentliche nie gesendet, Ihr Endpunkt sieht sie also nie und Ihre Server-Logs zeigen nichts. Nur Anfragen, die nicht einfach sind, erhalten einen Preflight.
Content-Type steht nur für application/x-www-form-urlencoded, multipart/form-data und text/plain auf der CORS-Safelist. Diese drei und sonst nichts. Ein JSON-Body stellt die Anfrage außerhalb der Safelist, der Browser kündigt sie deshalb im Voraus an. Deshalb erzeugt das Hinzufügen einer JSON-API zu einer bestehenden Seite plötzlich eine OPTIONS-Anfrage, die niemand geschrieben hat.
Weil eine Antwort, die an einen angemeldeten Nutzer gebunden ist, nicht für jede Website lesbar sein darf, die dieser Nutzer besucht. Wenn eine Anfrage Cookies oder HTTP-Authentifizierung sendet, muss der Server den Origin nennen, dem er vertraut, und ein Browser lehnt eine Wildcard rundweg ab, selbst zusammen mit Access-Control-Allow-Credentials: true. Dasselbe gilt für ein Sternchen in Allow-Methods, Allow-Headers und Expose-Headers: Bei einer Anfrage mit Credentials wird jedes davon als wörtlicher Header-Name gelesen und nicht als Wildcard.
Nein. CORS entscheidet, welche Origins eine Antwort innerhalb eines Browsers lesen dürfen. Es ist keine Authentifizierung, es vergibt keine Berechtigungen, und es verhindert keine Cross-Site Request Forgery, weil ein CSRF-Angriff die Antwort nicht lesen muss. Jeder Client, der kein Browser ist, ignoriert es vollständig. Behalten Sie Ihre Authentifizierung, Ihre Autorisierungsprüfungen und Ihre CSRF-Token genau so bei, wie sie sind.
Von POLPROG Servern an den von Ihnen genannten Endpunkt, weil ein Browser diese Diagnose nicht an sich selbst durchführen kann: CORS ist genau das, was ihn daran hindern würde. Es werden nur die für die Analyse nötigen Header gesendet, kein Cookie von Ihnen wird weitergeleitet, es wird nie ein Request-Body gesendet, und Response-Bodies werden verworfen. Nichts wird gespeichert, sobald der Bericht bei Ihnen ist, und Werte sensibler Header wie Authorization werden nie angezeigt oder exportiert.
Ein Unternehmen sucht häufig „einen Security Scanner“. Tatsächlich müssen mehrere unterschiedliche Probleme gelöst werden:
HTTP-Sicherheitsheader übermitteln dem Browser Regeln für Skripte, Styles, Frames, Gerätefunktionen, Referrer-Daten, MIME-Typen und HTTPS. Eine passende Konfiguration begrenzt Auswirkungen von XSS, Clickjacking, MIME Confusion, XS-Leaks und unerwünschtem Cross-Origin-Einbetten.
Ein gutes Website-Audit ist weder eine einzelne Lighthouse-Punktzahl noch eine Liste mit mehreren Dutzend automatischen Warnungen. Es sollte vier Fragen beantworten: Kann eine Suchmaschine die Website korrekt finden und verstehen? Kann ein Nutzer seine Aufgabe effizient erledigen? Ist die Website schnell genug? Und setzt sie den Betreiber oder die Besucher unnötigen Risiken aus?
Wir entwickeln individuelle Software und Lösungen, die auf Ihre Bedürfnisse zugeschnitten sind.