CORS-Sicherheit mit mobilen Apps

Wir denken also darüber nach, dem erlaubten Ursprung null hinzuzufügen. Es ist besser, da es jede andere Website blockiert, die versucht, unsere API abzurufen, es aber jeder mobilen App ermöglicht, sie abzurufen ...

Wenn Sie dies tun, lassen Sie Anforderungen von JavaScript-Code zu, der von jedem Nicht-http/https-Ursprung ausgeführt wird - dies schließt alle ein, die irgendetwas von a ausführen file:// oder auch data: URL.

Wenn Sie also aus "Sicherheitsgründen" eine restriktive CORS-Richtlinie verwenden, senden Sie die Antworten mit einem Access-Control-Allow-Origin: null Header klingt nach einer ziemlich schlechten Idee.

Wir müssen unsere API-Server-Sicherheit mit CORS-Einschränkung beibehalten: Alle Lösungen, die ich gefunden habe, weisen mich an, alle zuzulassen. Origin: *, aber dies wäre ein großer Sicherheitsfehler für unsere API.

Sie erklären nicht, warum Sie einen Sicherheitsfehler festgestellt haben oder warum Sie überhaupt eine restriktive CORS-Richtlinie benötigen. Aber wenn (1) Ihr Webserver nicht in einem Intranet oder hinter einer anderen Art von Firewall ausgeführt wird und (2) der Zugriff auf die Ressourcen ansonsten nur durch die IP-Authentifizierung eingeschränkt ist, profitieren Sie von einer restriktiven CORS-Richtlinie nicht . Zu zitiere die Spezifikation :

Grundlegende Einrichtung des sicheren CORS-Protokolls

Für Ressourcen, bei denen Daten durch IP-Authentifizierung oder eine Firewall geschützt sind (leider noch relativ häufig), ist die Verwendung des CORS-Protokolls nicht sicher. (Dies ist der Grund, warum das CORS-Protokoll erfunden werden musste.)

Andernfalls ist die Verwendung des folgenden Headers jedoch sicher:

Access-Control-Allow-Origin: *

Selbst wenn eine Ressource zusätzliche Informationen basierend auf Cookie- oder HTTP-Authentifizierung bereitstellt, wird sie durch die Verwendung des obigen Headers nicht angezeigt. Die Ressource wird mit APIs wie XMLHttpRequest geteilt, ähnlich wie es bereits mit curl und wget geteilt wird.

Mit anderen Worten, wenn auf eine Ressource von einem zufälligen Gerät aus, das mit curl und wget mit dem Web verbunden ist, nicht zugegriffen werden kann, darf der oben genannte Header nicht enthalten sein. Wenn jedoch darauf zugegriffen werden kann, ist dies vollkommen in Ordnung.

Wie in der Antwort von sideshowbarker unter Verwendung von Access-Control-Allow-Origin: null kann nicht als sicher angesehen werden, wenn die App in einem Browserkontext geöffnet werden kann. Es stellt jedoch kein Sicherheitsrisiko für eine App dar, die in ihrer eigenen dedizierten Webansicht ausgeführt wird.

Die Same Origin Policy (die CORS erweitert) wurde für eine bestimmte Art von Bedrohung entwickelt: Ein Skript aus einer fremden Domäne, das im Browser ausgeführt wird und eine Anfrage an Ihren Server sendet, die Ihre Autorisierungs-Cookies enthält. Wenn Sie Ihre App jedoch in einem dedizierten WKWebView ausführen, gibt es keine fremden Skripte, die mithilfe Ihrer Cookies eine Anfrage an Ihren Server stellen können.