VoriTools

Analyseur d’en-têtes CORS

Renseignez les champs de la requête. Aucun appel n’est envoyé ; le comportement serveur et les restrictions de valeurs restent à tester.

Fonctionne localement dans votre navigateur
Voir la catégorie: Développement d’API (15)
Tout dans cet outil est traité dans ce navigateur. VoriTools ne télécharge pas, ne stocke pas et n’appelle aucune API tierce avec votre entrée.
Requête du navigateur et en-têtes de réponse copiésCe vérificateur modélise uniquement les règles du navigateur ; il ne contacte pas le API ni ne rejoue les informations d'identification.

Modéliser une requête CORS du navigateur à partir d’en-têtes de réponse copiés

Cet analyseur modélise une requête CORS du navigateur à partir des en-têtes de réponse que vous collez. Il répond à une seule question : le navigateur laisserait-il la page lire cette réponse, et le preflight, quand il est nécessaire, serait-il accepté ?

Tout s’exécute dans l’onglet. Aucune requête n’est envoyée : le résumé décrit ce que permettent les en-têtes copiés, pas ce que renvoie le serveur réel aujourd’hui.

  1. Saisissez l’origine de la requête (schéma, hôte, port) et choisissez la méthode. PUT, PATCH et DELETE déclenchent un preflight ; GET, HEAD et POST en général pas.
  2. Listez les en-têtes que le navigateur mettrait dans Access-Control-Request-Headers, par exemple Authorization, X-Request-ID, et cochez les informations d’identification quand la requête envoie des cookies ou une authentification HTTP.
  3. Collez le bloc complet d’en-têtes de réponse sous forme de lignes `Nom: valeur`, puis cliquez sur Analyser la politique CORS.
  4. Lisez d’abord la décision, puis les vérifications : chaque ligne nomme l’en-tête qui a autorisé ou bloqué la requête. Copiez ou téléchargez le résumé pour le conserver.

Comment l’analyseur lit les en-têtes Access-Control et où il s’arrête

Correspondance d’origine et informations d’identification

Access-Control-Allow-Origin doit reprendre l’origine exacte de la requête : schéma et hôte en minuscules, ports par défaut omis, sans barre oblique finale. Chrome refuse `https://app.example.com/` pour l’origine `https://app.example.com`, et l’analyseur signale la même divergence.

`*` autorise toutes les origines uniquement si la requête n’envoie pas d’informations d’identification. Avec des cookies ou une authentification HTTP, la réponse doit reprendre l’origine et ajouter `Access-Control-Allow-Credentials: true` ; l’origine joker est alors bloquée même si elle paraît permissive.

Ce qui exige un preflight et ce qui passe sans lui

Un Content-Type JSON ou un en-tête personnalisé font envoyer un preflight OPTIONS avant la requête. Chrome exige alors une entrée correspondante dans Access-Control-Allow-Methods et dans Access-Control-Allow-Headers pour chaque en-tête listé ; sans elles la réponse est bloquée, alors que `text/plain` passe avec la même politique.

GET, HEAD et POST sont des méthodes de la liste blanche CORS : elles passent le preflight même si Access-Control-Allow-Methods ne les liste pas. PUT, PATCH et DELETE doivent être listés. Les noms de méthode et d’en-tête sont comparés sans tenir compte de la casse : `post` et `x-test` correspondent.

Les jokers qui cessent de valoir avec des informations d’identification

`Access-Control-Allow-Methods: *` et `Access-Control-Allow-Headers: *` ne sont des jokers que pour les requêtes sans informations d’identification. Une requête avec informations d’identification a besoin de sa méthode et de chaque en-tête listés littéralement, et l’analyseur le dit maintenant au lieu de faire confiance à l’astérisque.

Ce que l’analyseur ne fait pas : il n’envoie pas la requête et ne rejoue pas les informations d’identification, ne juge pas les restrictions de valeur d’en-tête (un schéma Authorization, une valeur de Content-Type) et ne couvre pas les redirections, les origines nulles, Access-Control-Expose-Headers, Max-Age ni Vary.

Outils récents :