Solutions APISIX pour les défis liés au cross-origin

Dans le développement d'applications web, les problèmes de cross-origin sont devenus un sujet populaire. Cependant, avec l'adoption généralisée des passerelles API, nous disposons désormais d'une solution plus pratique et efficace pour résoudre les problèmes de cross-origin. La passerelle API, en tant que composant clé de l'architecture des applications, fournit non seulement des fonctionnalités telles que le routage des requêtes et la gestion des API, mais gère également efficacement les requêtes cross-origin, aidant les développeurs à contourner les restrictions de la politique de même origine des navigateurs. Cet article explorera en détail comment utiliser la passerelle API APISIX pour résoudre les problèmes de cross-origin.

Qu'est-ce que le Cross-Origin ?

Les problèmes de cross-origin proviennent principalement de la politique de même origine appliquée par les navigateurs. La politique de même origine exige que la source (protocole, domaine, port) d'une requête soit exactement identique à celle de la ressource cible ; sinon, le navigateur bloquera la requête. Cette politique vise à protéger la sécurité des informations des utilisateurs et à empêcher les sites web malveillants de voler des données. Cependant, dans le développement pratique, des scénarios tels que la séparation frontend-backend ou le déploiement avec des domaines ou ports différents entraînent souvent des problèmes de cross-origin.

Résolution des Problèmes de Cross-Origin avec APISIX

CORS (Cross-Origin Resource Sharing)

CORS (Cross-Origin Resource Sharing) est une norme W3C qui permet aux navigateurs d'envoyer des requêtes à des serveurs cross-origin, surmontant les restrictions imposées par la politique de même origine. Dans APISIX, les développeurs peuvent facilement configurer des règles CORS en utilisant le plugin CORS, spécifiant quelles sources sont autorisées à accéder aux ressources.

Exemple de commande utilisant curl pour configurer CORS dans APISIX :

curl http://127.0.0.1:9180/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d ' { "uri": "/hello", "plugins": { "cors": {} }, "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:8080": 1 } } }'

Cette commande utilise curl pour envoyer une requête PUT à l'API Admin d'APISIX, créant une route avec l'ID 1. La route est configurée avec un chemin URI de /hello, et la configuration par défaut active le plugin CORS. De plus, le serveur en amont est spécifié comme 127.0.0.1:8080.

L'exécution d'une requête de test donnera les résultats de la configuration par défaut :

curl http://127.0.0.1:9080/hello -v

...
< Server: APISIX web server
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: *
< Access-Control-Allow-Headers: *
< Access-Control-Expose-Headers: *
< Access-Control-Max-Age: 5
...

Si des ajustements à la politique CORS sont nécessaires, il suffit de modifier les configurations pertinentes du plugin. Voici plusieurs options de configuration couramment utilisées :

• allow_origins : Spécifie les origines autorisées pour l'accès cross-origin. Cela peut être une URL spécifique ou utiliser le caractère générique '*' pour autoriser toutes les origines. Plusieurs valeurs sont séparées par des virgules.

• allow_methods : Définit les méthodes HTTP autorisées pour l'accès cross-origin, telles que GET, POST, etc. Plusieurs valeurs sont séparées par des virgules.

• allow_headers : Permet aux champs d'en-tête personnalisés d'être inclus dans les requêtes cross-origin. Plusieurs valeurs sont séparées par des virgules.

• expose_headers : Spécifie les champs d'en-tête personnalisés à exposer dans les réponses cross-origin. Plusieurs valeurs sont séparées par des virgules.

• max_age : Définit le temps maximum pour que le navigateur mette en cache les réponses CORS.

• allow_credentials : Détermine s'il est permis de transporter des informations d'identification (comme les cookies) dans les requêtes cross-origin.

Points à Noter

Une attention particulière doit être portée au fait que bien que CORS soit facile à utiliser, son activation peut entraîner des problèmes de sécurité. Cela est principalement dû au fait que CORS assouplit les restrictions imposées par la politique de même origine, permettant à des requêtes provenant de différentes origines d'accéder aux ressources.

Dans ce contexte, concentrons-nous sur allow_credentials. allow_credentials est un élément de configuration crucial dans CORS, déterminant si les requêtes cross-origin sont autorisées à transporter des informations d'authentification. Cela inclut, mais ne se limite pas à des données sensibles, y compris les cookies, les informations d'authentification HTTP ou les certificats SSL clients.

Par défaut, allow_credentials est désactivé, ce qui signifie qu'il ne permet pas de transporter des informations d'authentification. Cependant, si CORS est activé et qu'il permet de transporter des informations d'authentification (allow_credentials: true), une prudence supplémentaire est nécessaire. Cela implique que les requêtes provenant d'autres origines peuvent également accéder à des ressources protégées, potentiellement exécutant des opérations sensibles. Par exemple, un site web malveillant exploitant cette vulnérabilité de configuration pourrait inciter les utilisateurs à initier des requêtes cross-origin, entraînant le vol de leurs cookies de session ou des actions non autorisées.

Pour minimiser les problèmes de sécurité potentiels lors de l'activation des requêtes cross-origin, il est conseillé de suivre les meilleures pratiques suivantes :

1. Configurer soigneusement allow_origin : Évitez de définir allow_origin à * (autoriser toutes les origines) de manière indiscriminée. Spécifiez explicitement les origines autorisées.
2. Limiter allow_credentials : Activez allow_credentials uniquement lorsque nécessaire et restreignez-le à des origines de confiance.
3. Utiliser un protocole de transport sécurisé : Assurez-vous que les requêtes CORS sont transmises via HTTPS pour prévenir les attaques de type man-in-the-middle.
4. Validation et autorisation : Sur le serveur backend, implémentez des vérifications de validation et d'autorisation appropriées pour les requêtes cross-origin, garantissant que seuls les utilisateurs autorisés peuvent accéder aux ressources sensibles.
5. Éviter d'utiliser des méthodes HTTP non sécurisées : Limitez les méthodes HTTP utilisées dans les requêtes cross-origin, en autorisant uniquement des méthodes sûres telles que GET et POST, tout en désactivant des méthodes potentiellement risquées comme PUT et DELETE, qui peuvent poser des risques de sécurité.

Proxy Inverse

En plus d'utiliser CORS, APISIX peut indirectement résoudre les problèmes de cross-origin en se configurant comme un proxy inverse. Un proxy inverse est un modèle d'architecture de serveur courant où le serveur proxy inverse agit comme un intermédiaire entre le client et le serveur cible. Lorsqu'un client initie une requête, ces requêtes sont d'abord envoyées au serveur proxy inverse, qui les transmet ensuite au serveur cible réel. Une fois le traitement terminé, la réponse du serveur cible est renvoyée au proxy inverse, puis finalement transmise au client.

Il est crucial de comprendre qu'un proxy inverse ne résout pas directement les problèmes de cross-origin, mais contourne astucieusement les restrictions de la politique de même origine des navigateurs. Lorsqu'un client doit effectuer une requête cross-origin, il envoie en réalité la requête au serveur proxy inverse plutôt qu'au serveur cible directement. Comme le serveur proxy inverse et le serveur cible sont généralement dans le même environnement réseau ou configuration, leur communication n'est pas soumise aux restrictions de la politique de même origine. Cela permet au serveur proxy inverse de transmettre librement les requêtes du client au serveur cible et de renvoyer les réponses au client, atteignant ainsi indirectement l'objectif d'accès cross-origin.

Comme APISIX sert de passerelle API, il est naturellement positionné pour être déployé entre le client et le serveur. Par conséquent, dans des applications de plus petite envergure, déployer l'application client et APISIX dans le même domaine et modifier l'adresse de requête du client pour qu'elle pointe vers l'adresse du service APISIX garantit un accès fluide du client à APISIX. Cela peut exploiter la fonctionnalité de proxy inverse pour fournir un accès cross-origin au client. De plus, d'autres plugins peuvent être combinés pour assurer la sécurité et la fiabilité de l'ensemble du processus de communication.

Conclusion

Dans cet article, nous avons exploré comment utiliser APISIX pour résoudre les problèmes de cross-origin, en mettant l'accent sur deux méthodes : CORS et le proxy inverse. En configurant correctement le plugin CORS, nous pouvons assouplir les restrictions de la politique de même origine imposées par les navigateurs, permettant aux requêtes cross-origin d'accéder aux ressources. D'autre part, le proxy inverse agit comme un intermédiaire, contournant la politique de même origine des navigateurs et facilitant l'accès cross-origin. Chaque méthode a ses avantages, et le choix de la solution appropriée dépend des besoins spécifiques. Que ce soit en utilisant CORS ou le proxy inverse, APISIX offre des fonctionnalités flexibles et puissantes, aidant les développeurs à résoudre de manière transparente les problèmes de cross-origin et à assurer le fonctionnement normal et l'expérience utilisateur des applications.