Was ist eine Preflight-Anfrage

Was ist eine Preflight-Anfrage?

Wir alle wissen, dass gängige Browseranfragen POST, GET, PUT, DELETE usw. umfassen. Haben Sie jedoch jemals bemerkt, dass es einen weiteren Anfrage-Typ namens OPTIONS gibt?

Im Allgemeinen bezieht sich eine Preflight-Anfrage auf eine OPTIONS-Anfrage. Sie wird automatisch vom Browser gesendet, wenn dieser feststellt, dass eine bevorstehende Anfrage unvorhersehbare Auswirkungen auf den Server haben könnte. Durch die Preflight-Anfrage kann der Browser feststellen, ob der Server die Fortsetzung der bevorstehenden Anfrage zulässt. Nur wenn die Erlaubnis erteilt wird, führt der Browser die eigentliche Anfrage aus.

In der Regel erfordern Preflight-Anfragen keine Benutzerverwaltung oder Intervention – sie werden automatisch vom Browser und dem Server behandelt.

Eine Preflight-Anfrage sieht typischerweise wie folgt aus:

Access-Control-Request-Headers: x-requested-with
Access-Control-Request-Method: POST
Origin: http://preflight.example.com

Die drei wichtigsten Felder in dieser Anfrage sind:

1. Origin – Repräsentiert die Quelle der Anfrage.
2. Access-Control-Request-Method – Gibt die tatsächlich angeforderte HTTP-Methode an.
3. Access-Control-Request-Headers – Listet die tatsächlichen Anfrage-Header auf.

Die Antwort auf eine Preflight-Anfrage sieht normalerweise wie folgt aus:

Access-Control-Allow-Headers: Content-Type, Content-Length, Authorization, Accept, X-Requested-With
Access-Control-Allow-Origin: http://preflight.example.com
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE
Access-Control-Max-Age: 86400

Die wichtigsten Felder in der Antwort sind:

1. Access-Control-Allow-Origin – Gibt an, welche Ursprünge auf die Ressource zugreifen dürfen.
2. Access-Control-Allow-Headers – Listet die zulässigen benutzerdefinierten Anfrage-Header auf.
3. Access-Control-Allow-Methods – Gibt die zulässigen HTTP-Methoden an.

Wenn irgendein Aspekt der tatsächlichen Anfrage nicht in den zulässigen Bereich fällt, bricht der Browser die Anfrage automatisch ab und wirft einen CORS-Fehler aus.

Das letzte Feld, Access-Control-Max-Age, definiert die Lebensdauer der Preflight-Anfrage. Während dieser Zeit sendet der Browser keine weitere Preflight-Anfrage für dieselbe Anfrage.

Wann wird eine Preflight-Anfrage ausgelöst?

Eine Preflight-Anfrage ist Teil der CORS-Spezifikation (Cross-Origin Resource Sharing), und alle modernen Browser implementieren sie. Einige Browser erweitern den Standard jedoch um zusätzliche Funktionen.

Laut MDN müssen fünf Bedingungen erfüllt sein, um das Auslösen einer Preflight-Anfrage zu vermeiden. Wenn eine dieser Bedingungen nicht erfüllt ist, sendet der Browser eine Preflight-Anfrage, bevor er die eigentliche Anfrage ausführt, um unvorhersehbares Serververhalten zu verhindern.

Die fünf Bedingungen sind:

1. Einschränkung der Anfrage-Methode – Die Anfrage-Methode muss GET, POST oder HEAD sein.
2. Einschränkung des Anfrage-Headers – Nur die folgenden neun Header sind erlaubt:
   • Accept
   • Accept-Language
   • Content-Language
   • Content-Type
   • DPR
   • Downlink
   • Save-Data
   • Viewport-Width
   • Width
3. Einschränkung des Content-Type – Der Content-Type darf nur einer der folgenden sein:
   • text/plain
   • multipart/form-data
   • application/x-www-form-urlencoded
4. XMLHttpRequestUpload-Objekt-Einschränkung – Es sollten keine Event-Listener auf dem XMLHttpRequestUpload-Objekt registriert sein.
5. ReadableStream-Objekt-Einschränkung – Die Anfrage darf kein ReadableStream-Objekt enthalten.

Für die meisten Entwickler sind die Haupteinschränkungen die ersten drei Regeln. Die häufigsten Auslöser für Preflight-Anfragen sind:

• Verwendung von benutzerdefinierten Anfrage-Headern
• Verwendung eines Content-Type, der nicht zu den erlaubten Typen gehört

Warum gibt es Preflight-Anfragen?

Nachdem wir nun verstanden haben, was eine Preflight-Anfrage ist und wann sie ausgelöst wird, wollen wir untersuchen, warum sie entworfen wurde.

Die Preflight-Anfrage ist ein wesentlicher Bestandteil von CORS und dient dazu, die Websicherheit zu erhöhen, indem der Cross-Origin-Zugriff eingeschränkt wird.

Ohne CORS wären alle Webressourcen für jede Website zugänglich, sofern sie nicht explizit eingeschränkt sind. Zum Beispiel:

• Website A könnte JavaScript verwenden, um auf Website B's Cookies und private Daten zuzugreifen.
• Website B könnte dasselbe mit Website A tun.

CORS verhindert standardmäßig unautorisierte Cross-Origin-Anfragen. Nur zugelassene Ursprünge, Methoden und Header können auf geschützte Ressourcen zugreifen. Dieses Sicherheitsmodell stellt sicher, dass Websites, die Schutz benötigen, den Zugriff kontrollieren können, während sie gleichzeitig Flexibilität beibehalten, wenn Cross-Origin-Zugriff erforderlich ist.

Preflight-Anfragen helfen, Sicherheitsrisiken zu verhindern, indem sie:

• Sicherstellen, dass der Server Cross-Origin-Anfragen explizit erlaubt, bevor er sie ausführt.
• Älteren Servern ermöglichen, die CORS nicht unterstützen, unbefugte Anfragen zu blockieren, bevor sensible Daten offengelegt werden.

Wenn Sie sich für CORS-Sicherheitsmechanismen interessieren, können Sie die MDN-Dokumentation für einen tieferen Einblick konsultieren.

Wie man Preflight-Anfragen richtig unterstützt

Wenn Sie ein Backend-Entwickler sind, müssen Sie möglicherweise Ihren Server konfigurieren, um Preflight-Anfragen richtig zu behandeln.

Um Preflight-Anfragen zu unterstützen, konzentrieren Sie sich auf drei wichtige Antwort-Header:

1. Access-Control-Allow-Origin

   • Dieser gibt an, welche Ursprünge auf die Ressource zugreifen dürfen.
   • Wenn die API öffentlich ist (z. B. ein Image-Upload-Service), können Sie dies auf "*" setzen (alle Ursprünge zulassen).
   • Die Verwendung von "*" reduziert jedoch die Sicherheit, daher wird sie im Allgemeinen nicht empfohlen.

2. Access-Control-Allow-Headers

   • Dieser gibt an, welche benutzerdefinierten Anfrage-Header zulässig sind.
   • Server sollten explizit nur die Header auflisten, die sie unterstützen.

3. Access-Control-Allow-Methods

   • Dieser gibt an, welche HTTP-Methoden erlaubt sind.
   • Anstatt "*" ist es sicherer, nur die erforderlichen Methoden aufzulisten.

Empfohlene Konfiguration:

ctx.set('Access-Control-Allow-Origin', '<allowed-origin>');
ctx.set('Access-Control-Allow-Credentials', true);
ctx.set('Access-Control-Max-Age', 86400000);
ctx.set('Access-Control-Allow-Methods', 'OPTIONS, HEAD, <actual-method>');
ctx.set(
  'Access-Control-Allow-Headers',
  'Content-Type, Content-Length, Authorization, Accept, X-Requested-With'
);

Zusätzlich, wenn Sie router.post() oder andere Kurzschreibmethoden verwenden in Ihrem Backend-Framework, müssen Sie OPTIONS-Anfragen explizit behandeln, um sicherzustellen, dass der Browser sie korrekt verarbeiten kann.

Ein gängiger Ansatz ist, HTTP 200 (OK) oder HTTP 204 (No Content) für OPTIONS-Anfragen zurückzugeben:

if (ctx.request.method === 'OPTIONS') {
  ctx.response.status = 204;
}

Hinweis: Während jeder 2xx Status Code akzeptabel ist, ist 204 No Content die häufigste Wahl.

Die Beziehung zwischen Preflight-Anfragen und CORS

Laut MDN sind Preflight-Anfragen Teil des CORS-Standards. Sie treten nur auf, wenn eine Anfrage Cross-Origin ist.

Das bedeutet:

• Cross-Origin-Anfragen lösen nicht immer eine Preflight-Anfrage aus.
• Wenn eine Preflight-Anfrage auftritt, ist die Anfrage definitiv Cross-Origin.

Dies ist sinnvoll, da Preflight-Anfragen existieren, um Cross-Origin-Interaktionen zu sichern. Innerhalb des gleichen Ursprungs haben Backend- und Frontend-Entwickler in der Regel ein gegenseitiges Verständnis der API-Sicherheit, was Preflight-Prüfungen unnötig macht.

Dies ist ein klassisches Beispiel für das Ausbalancieren von Sicherheit und Bequemlichkeit – die Wahl eines Kompromisses, der die Sicherheit verbessert, ohne die Entwicklung zu restriktiv zu gestalten.

---

Wir sind Leapcell, Ihre beste Wahl für das Hosting von Backend-Projekten.

Leapcell ist die Next-Gen Serverless Plattform für Web Hosting, Async Tasks und Redis:

Multi-Language Support

• Entwickeln Sie mit Node.js, Python, Go oder Rust.

Stellen Sie unbegrenzt Projekte kostenlos bereit

• Zahlen Sie nur für die Nutzung - keine Anfragen, keine Gebühren.

Unschlagbare Kosteneffizienz

• Pay-as-you-go ohne Leerlaufgebühren.
• Beispiel: 25 $ unterstützen 6,94 Mio. Anfragen bei einer durchschnittlichen Antwortzeit von 60 ms.

Optimierte Entwicklererfahrung

• Intuitive Benutzeroberfläche für mühelose Einrichtung.
• Vollständig automatisierte CI/CD-Pipelines und GitOps-Integration.
• Echtzeit-Metriken und -Protokollierung für verwertbare Erkenntnisse.

Mühelose Skalierbarkeit und hohe Leistung

• Auto-Skalierung zur einfachen Bewältigung hoher Parallelität.
• Null Betriebsaufwand - konzentrieren Sie sich einfach auf das Bauen.

Erfahren Sie mehr in der Dokumentation!

Folgen Sie uns auf X: @LeapcellHQ