Un VPN ne peut pas désactiver CORS, il change la réponse

Commencez par séparer deux choses qui ont changé en même temps : le chemin réseau et l’application par le navigateur. Un VPN change l’adresse de sortie ; il ne change pas l’origine de la page, qui se compose du schéma, de l’hôte et du port. Si la requête réussit maintenant, quelque chose dans la réponse a changé, ou la requête elle-même. Déterminer lequel, c’est toute l’enquête.

CORS est un protocole d’en-têtes appliqué par le navigateur, donc rien sur le chemin réseau ne peut le désactiver.

L’origine n’est pas une adresse IP

Une origine est un schéma, un hôte et un port. Ce n’est pas l’adresse d’où partent les paquets, et ce n’est pas l’IP que voit le serveur. C’est pourquoi un VPN peut changer chaque adresse observable et laisser l’origine identique. Le navigateur compare l’Access-Control-Allow-Origin de la réponse à l’origine de la page, et l’adresse de sortie n’entre jamais dans cette comparaison.

Une extension ou un proxy qui semble corriger une erreur CORS fait donc autre chose : il réécrit des en-têtes ou route la requête pour qu’elle ne soit plus cross-origin. Ni l’un ni l’autre n’est une propriété du VPN.

Ce que le navigateur envoie réellement

Pour une requête cross-origin qui n’est pas simple, le navigateur envoie d’abord une pré-vérification OPTIONS portant la méthode et les en-têtes prévus. Le serveur doit répondre avec les autorisations qu’il accorde, et la vraie requête ne suit que si cette réponse satisfait les règles. Un VPN change le chemin qui transporte les deux échanges et peut changer ce que répondent les services intermédiaires. Il ne change ni la chaîne d’origine ni l’exigence de pré-vérification.

Un client en ligne de commande n’affiche généralement rien de tout cela. Il peut ne pas envoyer l’en-tête Origin, saute souvent la pré-vérification et peut porter d’autres identifiants. Un corps renvoyé à curl prouve que le serveur a répondu à curl.

Trouvez la réponse qui a changé

Comparez la réponse réelle sur chaque chemin, pas seulement le code de statut. Regardez les en-têtes portant les autorisations CORS, le type de contenu, toute redirection, et si une variante WAF ou CDN a produit une autre page. Un refus régional, une redirection d’authentification ou une page d’erreur sans l’en-tête d’autorisation échouent tous dans le navigateur tout en ressemblant à un bug CORS. Ce sont des différences de chemin de livraison, et c’est ce qu’il faut documenter.

Capturez les en-têtes de réponse des deux chemins et comparez-les ligne par ligne. Si la seule différence est l’absence d’Access-Control-Allow-Origin sur une page d’erreur, vous avez trouvé la cause.

Corrigez le service, pas l’application

Quand le service est le vôtre, énoncez explicitement les origines autorisées et les fonctionnalités de la requête, puis lisez les erreurs que produisent son frontend et ses intermédiaires. Si vous ne le faites pas, envoyez au propriétaire du service une comparaison assainie. N’incluez jamais de cookies, d’en-têtes d’autorisation ni d’exports de session dans ce rapport, car ce sont les identifiants que la politique existe pour protéger.

Évitez les extensions de navigateur qui désactivent CORS. Elles changent la frontière de sécurité tout en masquant la différence de réponse qu’il fallait expliquer, et elles laissent la même panne en place pour tous les autres utilisateurs.

Consignez les deux réponses, l’origine utilisée et le chemin suivi. Ce relevé transforme une rumeur sur le VPN en un bug du service.