Beginnen Sie damit, zwei Dinge zu trennen, die sich gleichzeitig geändert haben: den Netzwerkpfad und die Durchsetzung im Browser. Ein VPN ändert die Ausgangsadresse; es ändert nicht den Ursprung der Seite, der aus Schema, Host und Port besteht. Wenn die Anfrage jetzt erfolgreich ist, hat sich etwas in der Antwort geändert oder die Anfrage selbst. Herauszufinden, was davon, ist die ganze Untersuchung.

CORS ist ein Header-Protokoll, das der Browser durchsetzt, daher kann nichts auf dem Netzwerkpfad es abschalten.

Der Ursprung ist keine IP-Adresse

Ein Ursprung ist ein Schema, ein Host und ein Port. Er ist nicht die Adresse, von der Pakete ausgehen, und nicht die IP, die der Server sieht. Deshalb kann ein VPN jede beobachtbare Adresse ändern und den Ursprung identisch lassen. Der Browser vergleicht den Access-Control-Allow-Origin der Antwort mit dem Ursprung der Seite, und die Ausgangsadresse kommt in diesen Vergleich nie hinein.

Eine Erweiterung oder ein Proxy, der einen CORS-Fehler zu beheben scheint, tut also etwas anderes: Er schreibt Header neu oder leitet die Anfrage so um, dass sie nicht mehr ursprungsübergreifend ist. Beides ist keine Eigenschaft des VPN.

Was der Browser tatsächlich sendet

Bei einer ursprungsübergreifenden Anfrage, die nicht einfach ist, sendet der Browser zuerst eine Vorabanfrage OPTIONS mit der beabsichtigten Methode und den Headern. Der Server muss mit den Berechtigungen antworten, die er erlaubt, und die eigentliche Anfrage folgt nur, wenn diese Antwort die Regeln erfüllt. Ein VPN ändert den Pfad, der beide Austausche trägt, und kann ändern, was zwischengeschaltete Dienste antworten. Es ändert nicht die Ursprungszeichenfolge oder die Anforderung der Vorabanfrage.

Ein Kommandozeilen-Client zeigt davon meist nichts. Er sendet möglicherweise keinen Origin-Header, überspringt oft die Vorabanfrage und trägt womöglich andere Anmeldedaten. Ein an curl zurückgegebener Body beweist, dass der Server curl geantwortet hat.

Finden Sie die Antwort, die sich geändert hat

Vergleichen Sie die tatsächliche Antwort über jeden Pfad, nicht nur den Statuscode. Achten Sie auf die Header mit CORS-Berechtigungen, den Inhaltstyp, jede Weiterleitung und ob eine WAF- oder CDN-Variante eine andere Seite erzeugt hat. Eine regionale Ablehnung, eine Authentifizierungsweiterleitung oder eine Fehlerseite ohne den Berechtigungs-Header scheitern alle im Browser, sehen aber wie ein CORS-Fehler aus. Das sind Unterschiede im Auslieferungspfad, und die gilt es zu dokumentieren.

Erfassen Sie die Antwort-Header beider Pfade und vergleichen Sie sie Zeile für Zeile. Wenn der einzige Unterschied der fehlende Access-Control-Allow-Origin auf einer Fehlerseite ist, haben Sie die Ursache gefunden.

Reparieren Sie den Dienst, nicht die Durchsetzung

Wenn der Dienst Ihnen gehört, nennen Sie die erlaubten Ursprünge und Anfragefunktionen ausdrücklich und lesen Sie dann die Fehler, die sein Frontend und seine Zwischenstellen erzeugen. Wenn nicht, senden Sie dem Diensteigentümer einen bereinigten Vergleich. Nehmen Sie niemals Cookies, Autorisierungs-Header oder Sitzungsexporte in diesen Bericht auf, denn das sind die Anmeldedaten, die die Richtlinie schützen soll.

Vermeiden Sie Browsererweiterungen, die CORS abschalten. Sie verändern die Sicherheitsgrenze, verbergen dabei den Antwortunterschied, der erklärt werden musste, und lassen denselben Fehler für alle anderen Nutzer bestehen.

Halten Sie beide Antworten fest, den verwendeten Ursprung und den genommenen Pfad. Dieser Nachweis macht aus einem VPN-Gerücht einen Dienstfehler.

Ähnliche Artikel