CORS - Est-ce une chose côté client, une chose côté serveur ou une chose au niveau du transport?
J'essaie de comprendre CORS . D'après ma compréhension, cela vous permet de limiter les domaines qui peuvent accéder à une ressource sur votre serveur. Cependant, cela ne semble pas être l'histoire complète. Par exemple, j'ai un service Web sans CORS activé. Je ne peux pas accéder à ce service Web à partir de mon application Web via jQuery (l'application s'exécute sur localhost). Cependant, je peux accéder au service Web de Postman. Donc, je suis un peu confus. Y a-t-il un travail supplémentaire côté client qui implique CORS?
Le serveur est responsable de signaler les origines autorisées. Le navigateur Web est chargé de veiller à ce que les demandes ne soient envoyées qu'à partir des domaines autorisés.
CORS est appliqué aux demandes lorsqu'un en-tête d'origine est inclus dans la demande. Cela inclut les demandes effectuées à partir de JavaScript et POST requêtes. Il n'est pas appliqué toutes les ressources. L'origine est le protocole, l'hôte et le port qui fait la demande. Les demandes effectuées par JavaScript utilisent l'origine qui a chargé le JavaScript, pas l'origine à partir de laquelle il a été chargé.
Lorsque CORS n'est pas activé, un navigateur s'appuiera sur même politique d'origine . La même politique d'origine n'est appliquée qu'aux scripts. Le navigateur autorise uniquement le chargement des scripts à partir de la même origine que la page chargée. La même politique d'origine est supposée lorsque les origines ne sont pas explicitement autorisées.
Un client HTTP autre qu'un navigateur n'utilisera ni la même politique d'origine ni CORS. Les demandes effectuées à partir de ces autres clients HTTP n'ont pas d'origine. À moins que l'application de bureau Postman n'émule un navigateur, elle pourra faire des demandes à n'importe quelle URL.
CORS et la même politique d'origine sont nécessaires car un navigateur ne fait pas implicitement confiance aux sites Web qu'il visite pour faire des demandes à d'autres sites Web. Ils ne protègent pas le site d'origine, ils protègent le site recevant les demandes d'origine croisées. C'est pourquoi les origines autorisées dépendent du serveur cible.
Sans ces politiques, un simple script qui charge à plusieurs reprises un site Web pourrait être distribué par des réseaux publicitaires ou par injection de script, puis tout navigateur chargeant le script contribuerait à une attaque par déni de service sur le site Web. Avec CORS et la même politique d'origine, un navigateur limitera l'impact de ce script.
Une autre protection importante offerte par CORS consiste à se protéger contre contrefaçon de demande intersite . Il empêche un site de faire certains types de demandes à un autre site. Ces demandes seraient effectuées à l'aide de tous les jetons créés précédemment, tels que les jetons de session.
CORS par exemple:
Un navigateur Web charge une page à partir de www.example.com. La page comprend un script qui fait une demande à www.example.org. L'origine de la demande est www.example.com. Le navigateur effectue la demande ou envoie d'abord une demande OPTIONS (la demande de contrôle en amont). Lorsque le serveur à www.example.org reçoit une demande d'une origine autre que www.example.org il répond avec un en-tête de réponse Access-Control-Allow-Origin qui indique au navigateur les origines autorisées à effectuer des requêtes. Il peut également répondre avec d'autres en-têtes comme Access-Control-Allow-Methods et Access-Control-Allow-Headers qui peut restreindre les types de demandes autorisées. Lorsque le navigateur est informé des origines autorisées, il bloque les demandes futures provenant d'origines non autorisées.
C'est un peu des deux en fait. Votre navigateur empêchera les demandes CORS à moins que l'origine de la demande (c'est-à-dire le domaine URL de référence) se trouve dans une liste blanche sur la destination, ou que la destination approuve toutes les demandes indépendamment de l'origine.
Dans les deux cas, l'en-tête requis (Access-Control-Allow-Origin) est ajouté, ce qui indique au navigateur qu'il est autorisé à envoyer la demande à la destination.
Cela garantit que les personnes mal intentionnées ne peuvent pas envoyer de demandes à un autre domaine sans que l'utilisateur ne le sache.