Comprendre et implémenter CORS dans NGINX : un guide détaillé - 🏆 Serveur géré

BLOG

15 septembre 2023

Comprendre et implémenter CORS dans NGINX : un guide détaillé

Découvrez ce qu'est CORS au niveau de l'en-tête HTTP et comment l'implémenter dans un environnement NGINX pour améliorer la sécurité et les fonctionnalités de votre site Web.

Dans le monde moderne du Web, la sécurité est une préoccupation majeure pour les développeurs et les administrateurs système. L’une des fonctionnalités de sécurité souvent sous-estimée mais fondamentale est celle du CORS, ou Cross-Origin Resource Sharing. Cette fonctionnalité est particulièrement pertinente pour les entreprises qui s'occupent d'hébergement et d'ingénierie système, en particulier celles qui utilisent des serveurs Web comme NGINX. Dans cet article, nous explorerons en détail ce que sont les CORS au niveau de l'en-tête HTTP et à quoi ils servent, avec un accent particulier sur la façon de les implémenter dans un environnement NGINX.

Qu’est-ce que CORS ?

CORS, acronyme de « Cross-Origin Resource Sharing », est un protocole de sécurité Web implémenté dans les navigateurs modernes pour contrôler et gérer les demandes de ressources entre différents domaines Web. En termes plus simples, CORS est un ensemble de règles et d'en-têtes HTTP qui permettent à un site Web d'accéder aux ressources d'un autre site Web sans violer la politique de même origine.

Politique de même origine

Pour bien comprendre l’importance du CORS, il est crucial de comprendre les politiques de même origine. Il s'agit d'une mesure de sécurité mise en œuvre dans les navigateurs pour limiter les interactions entre différents domaines. Selon cette politique, les scripts exécutés sur une page Web ne peuvent accéder qu'aux ressources du même domaine, protocole et port à partir desquels la page a été chargée. Par exemple, si un site Web sur http://dominioA.com essayez de faire une requête AJAX pour http://dominioB.com, la demande sera bloquée sauf si dominioB.com ne fournit pas les autorisations CORS adéquates.

Types de ressources

CORS est applicable à une variété de ressources Web, notamment :

  • fichier JavaScript
  • Feuilles de style CSS
  • Images et vidéos
  • Fonte
  • API RESTful et données JSON

Fonctionnement du CORS

Lorsqu'une ressource du domaine A tente d'accéder à une ressource du domaine B, le navigateur envoie une requête HTTP au domaine B. Cette requête comprend plusieurs en-têtes CORS, tels que Origin, qui indique de quel domaine provient la demande. Le serveur du domaine B peut alors répondre avec ses propres en-têtes CORS, tels que Access-Control-Allow-Origin, pour indiquer si la demande est autorisée ou non.

 

Si la demande est autorisée, le navigateur poursuit l'opération. Sinon, le navigateur bloque la requête et signale généralement une erreur dans la console de développement, vous indiquant que la requête a été bloquée en raison de la politique de même origine.

Contrôle en amont du CORS

Dans certains cas, avant d'envoyer la « vraie » requête, le navigateur envoie une requête préliminaire appelée « preflight » en utilisant la méthode HTTP OPTIONS. Il s’agit de vérifier si la prochaine demande peut être effectuée en toute sécurité. Le serveur répond à cette requête préliminaire avec les en-têtes CORS appropriés, indiquant si la requête initiale est autorisée.

CORS est en bref un mécanisme essentiel qui permet une plus grande interactivité et une plus grande intégration entre les sites Web, tout en maintenant des normes de sécurité élevées. Grâce à un ensemble d'en-têtes HTTP et de règles bien définies, CORS offre un moyen de contourner en toute sécurité les restrictions liées aux politiques de même origine, faisant ainsi du Web un environnement plus flexible et plus sécurisé.

Parce que c'est important ?

À l’ère du Web moderne, les applications sont souvent distribuées sur plusieurs domaines ou services. Par exemple, vous pourriez avoir une application frontale hébergée sur dominioA.com qui interagit avec un backend API sur dominioB.com. Dans un monde idéal, vous souhaiteriez que ces deux parties de l’application puissent communiquer librement entre elles pour offrir une expérience utilisateur fluide et fonctionnelle. Cependant, la réalité est un peu plus compliquée en raison d'une mesure de sécurité mise en œuvre dans les navigateurs appelée Same-Origin Policy.

La politique de même origine a été introduite pour protéger les utilisateurs contre les attaques potentielles de type Cross-Site Request Forgery (CSRF), Cross-Site Scripting (XSS) et d'autres types de vulnérabilités de sécurité qui peuvent survenir lorsque des sites Web d'origines différentes interagissent entre eux. En pratique, cette politique empêche une page Web d'effectuer des requêtes vers un autre domaine sans autorisation explicite. Ainsi, sans un mécanisme comme CORS, le navigateur bloquerait toute tentative du front-end vers dominioA.com faire des requêtes au backend sur dominioB.com.

Cela devient un problème important lorsqu'il s'agit d'applications Web modernes qui nécessitent un degré élevé d'interactivité et de fonctionnalités dynamiques. Par exemple, si vous disposez d'une boutique en ligne avec un panier qui doit vérifier la disponibilité d'un produit en temps réel, ou d'une application de réseau social qui doit charger des publications à partir d'un serveur API, la limitation imposée par la même politique d'origine pourrait représentent un obstacle insurmontable.

C'est là qu'intervient CORS. Avec CORS, vous pouvez définir des règles spécifiques sur le serveur backend qui permettent au frontend d'interagir avec lui même s'il est hébergé sur des domaines différents. Cela améliore non seulement la fonctionnalité et la convivialité des applications Web, mais le fait également de manière à maintenir des mesures de sécurité élevées. En d’autres termes, CORS offre le meilleur équilibre entre sécurité et fonctionnalité, permettant aux développeurs de créer des applications Web riches et interactives sans compromettre la sécurité de l’utilisateur final.

CORS au niveau de l'en-tête HTTP

CORS fonctionne en ajoutant de nouveaux en-têtes HTTP qui permettent aux serveurs de décrire quelles sources sont autorisées à accéder aux ressources d'un serveur Web. Certains des en-têtes CORS les plus courants incluent :

  • Access-Control-Allow-Origin: Spécifie quelles sources peuvent accéder à la ressource.
  • Access-Control-Allow-Methods: Spécifie les méthodes HTTP qui peuvent être utilisées lors de l'accès à la ressource.
  • Access-Control-Allow-Headers: Spécifie les en-têtes qui peuvent être utilisés lors d'une requête HTTP.

Implémentation CORS dans NGINX

NGINX est l'un des serveurs Web les plus populaires et offre une grande flexibilité pour configurer les paramètres CORS. Voici un exemple de la façon dont vous pouvez configurer CORS dans NGINX :

emplacement /api/ { if ($request_method = 'OPTIONS') { add_header 'Access-Control-Allow-Origin' '*'; add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS'; add_header 'Access-Control-Allow-Headers' 'DNT, User-Agent, X-Requested-With, If-Modified-Since, Cache-Control, Content-Type, Range'; add_header 'Access-Control-Max-Age' 1728000 ; add_header 'Content-Type' 'text/plain; jeu de caractères=utf-8'; add_header 'Contenu-Longueur' 0; retourner 204 ; } if ($request_method = 'POST') { add_header 'Access-Control-Allow-Origin' '*'; add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS'; add_header 'Access-Control-Allow-Headers' 'DNT, User-Agent, X-Requested-With, If-Modified-Since, Cache-Control, Content-Type, Range'; } if ($request_method = 'GET') { add_header 'Access-Control-Allow-Origin' '*'; add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS'; add_header 'Access-Control-Allow-Headers' 'DNT, User-Agent, X-Requested-With, If-Modified-Since, Cache-Control, Content-Type, Range'; } }

Dans cet exemple, nous avons utilisé la directive location pour spécifier que les règles CORS s'appliquent uniquement aux requêtes qui pointent vers la ressource /api/. Nous avons ensuite utilisé la variable $request_method pour appliquer différents ensembles d'en-têtes CORS en fonction de la méthode HTTP utilisée.

Considérations de sécurité

Alors que l'utilisation du caractère générique * dans l'en-tête Access-Control-Allow-Origin S’il est pratique d’autoriser n’importe quelle source à accéder à vos ressources, il s’agit également d’une pratique potentiellement dangereuse du point de vue de la sécurité. Nous vous recommandons de spécifier explicitement quelles sources sont autorisées.

conclusion

Les CORS sont un élément essentiel de la sécurité et des fonctionnalités du développement Web moderne. Ils permettent une communication sécurisée entre différents domaines, surmontant les limitations imposées par la même politique d'origine. La mise en œuvre de CORS dans NGINX est relativement simple mais nécessite une compréhension détaillée des en-têtes HTTP et des implications potentielles en matière de sécurité. Nous espérons que cet article vous a fourni les informations dont vous avez besoin pour implémenter CORS de manière efficace et sûre dans votre environnement NGINX.

Vous avez des doutes ? Vous ne savez pas par où commencer ? Contactez-nous !

Nous avons toutes les réponses à vos questions pour vous aider à faire le bon choix.

Discute avec nous

Discutez directement avec notre support avant-vente.

0256569681

Contactez-nous par téléphone pendant les heures de bureau 9h30 - 19h30

Contactez-nous en ligne

Ouvrez une demande directement dans l'espace contact.

INFORMATIONS

Managed Server Srl est un acteur italien leader dans la fourniture de solutions système GNU/Linux avancées orientées vers la haute performance. Avec un modèle d'abonnement peu coûteux et prévisible, nous garantissons que nos clients ont accès à des technologies avancées en matière d'hébergement, de serveurs dédiés et de services cloud. En plus de cela, nous proposons des conseils système sur les systèmes Linux et une maintenance spécialisée en SGBD, sécurité informatique, Cloud et bien plus encore. Nous nous distinguons par notre expertise dans l'hébergement de CMS Open Source de premier plan tels que WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart et Magento, soutenus par un service d'assistance et de conseil de haut niveau adapté aux administrations publiques, aux PME et à toutes tailles.

Red Hat, Inc. détient les droits de Red Hat®, RHEL®, RedHat Linux® et CentOS® ; AlmaLinux™ est une marque commerciale d'AlmaLinux OS Foundation ; Rocky Linux® est une marque déposée de la Rocky Linux Foundation ; SUSE® est une marque déposée de SUSE LLC ; Canonical Ltd. détient les droits sur Ubuntu® ; Software in the Public Interest, Inc. détient les droits sur Debian® ; Linus Torvalds détient les droits sur Linux® ; FreeBSD® est une marque déposée de la FreeBSD Foundation ; NetBSD® est une marque déposée de la Fondation NetBSD ; OpenBSD® est une marque déposée de Theo de Raadt. Oracle Corporation détient les droits sur Oracle®, MySQL® et MyRocks® ; Percona® est une marque déposée de Percona LLC ; MariaDB® est une marque déposée de MariaDB Corporation Ab ; REDIS® est une marque déposée de Redis Labs Ltd. F5 Networks, Inc. détient les droits sur NGINX® et NGINX Plus® ; Varnish® est une marque déposée de Varnish Software AB. Adobe Inc. détient les droits sur Magento® ; PrestaShop® est une marque déposée de PrestaShop SA ; OpenCart® est une marque déposée d'OpenCart Limited. Automattic Inc. détient les droits sur WordPress®, WooCommerce® et JetPack® ; Open Source Matters, Inc. détient les droits sur Joomla® ; Dries Buytaert détient les droits sur Drupal®. Amazon Web Services, Inc. détient les droits sur AWS® ; Google LLC détient les droits sur Google Cloud™ et Chrome™ ; Facebook, Inc. détient les droits sur Facebook® ; Microsoft Corporation détient les droits sur Microsoft®, Azure® et Internet Explorer® ; La Fondation Mozilla détient les droits sur Firefox®. Apache® est une marque déposée de The Apache Software Foundation ; PHP® est une marque déposée du groupe PHP. CloudFlare® est une marque déposée de Cloudflare, Inc. ; NETSCOUT® est une marque déposée de NETSCOUT Systems Inc. ; ElasticSearch®, LogStash® et Kibana® sont des marques déposées d'Elastic NV. Ce site n'est affilié, sponsorisé ou autrement associé à aucune des entités mentionnées ci-dessus et ne représente aucune de ces entités de quelque manière que ce soit. Tous les droits sur les marques et noms de produits mentionnés sont la propriété de leurs titulaires respectifs des droits d'auteur. Toutes les autres marques mentionnées appartiennent à leurs titulaires. MANAGED SERVER® est une marque déposée au niveau européen par MANAGED SERVER SRL Via Enzo Ferrari, 9 62012 Civitanova Marche (MC) Italie.

Retour en haut de page