14. Preflight : intention annoncée et demande réelle

Comprendre le mécanisme

Une pré-vérification CORS annonce au serveur la méthode et certains champs d’une demande envisagée. Elle utilise OPTIONS dans le cadre prévu par le navigateur. La réponse permet ou refuse cette intention selon la politique. Cette étape ne doit pas exécuter l’opération métier annoncée ni être assimilée à la demande authentifiée finale. Une réponse positive n’empêche pas le serveur de refuser ensuite une demande réelle invalide ou non autorisée.

Raisonner et vérifier

Vérifiez les deux échanges dans les outils réseau. Le cache de pré-vérification suit un mécanisme distinct du cache ordinaire d’une représentation ; une modification de politique peut donc sembler tarder. Documentez la durée et les limites imposées par les clients. N’autorisez pas toutes les méthodes simplement parce que le navigateur réclame une pré-vérification.

OPTIONS préalable

Le navigateur peut envoyer OPTIONS avant la requête réelle. Le précontrôle ne doit pas produire cet effet. Le navigateur peut annoncer méthode et headers envisagés avant la demande réelle. Le serveur répond selon sa politique de partage, mais aucune mutation métier ne devrait être exécutée pendant cette étape de négociation.

Sans preflight

Certaines requêtes ne déclenchent pas de preflight. Le déclenchement dépend notamment de la méthode et des champs. Certaines demandes remplissent les conditions d’un envoi sans pré-vérification. Ne fondez donc pas la protection d’une mutation sur l’idée que tout appel externe serait bloqué par un OPTIONS préalable.

Contrôles réels

La requête réelle doit conserver ses contrôles. Il ne vérifie pas la propriété métier de chaque objet. Après un preflight accepté, la demande réelle doit encore valider données, identité et autorisation. Une permission de communication n’est pas une permission de modifier une ressource précise.

Cache spécifique

Le cache de preflight possède un usage spécifique. Ses informations servent au contrôle de partage navigateur. Le navigateur peut mémoriser une réponse de preflight selon sa politique et la durée annoncée. Une modification serveur peut donc ne pas provoquer immédiatement un nouveau OPTIONS dans le même contexte.

Headers demandés

Le serveur doit examiner les en-têtes demandés selon son contrat. Les capacités doivent rester dans la politique définie. Examinez Access-Control-Request-Headers selon le contrat plutôt que recopier sans contrôle. L’admission d’un header ne prouve pas la fiabilité de sa valeur dans la demande réelle.

Refus préalable

Un preflight refusé peut empêcher l’envoi réel par le navigateur. Le refus peut être purement protocolaire. Un preflight refusé peut empêcher le navigateur d’émettre la demande réelle concernée. Vérifiez les journaux pour distinguer ce cas d’une demande envoyée dont seule la lecture de réponse est bloquée.

OPTIONS réussi

Un succès OPTIONS ne garantit pas le succès métier. Les deux échanges ont des responsabilités différentes. Le POST peut être refusé pour manque de droit après un OPTIONS réussi. Ce comportement est cohérent : les deux réponses portent sur des décisions différentes et doivent être testées séparément.

Méthode serveur

Les méthodes incorrectes doivent être refusées au serveur. Un client direct n’est pas limité par l’annonce navigateur. Le routeur doit refuser une méthode hors contrat indépendamment du navigateur. Un client autonome peut envoyer directement la demande sans passer par la séquence de preflight attendue.

Credentials du flux

Les credentials du flux réel demandent une validation propre. Le token doit encore être validé lors de l’opération. Les règles de cookies et d’authentification du flux réel restent applicables. Un OPTIONS ne démontre ni l’envoi d’un cookie ni la validité d’une session au moment du POST.

Suite complète

Tester OPTIONS seul ne couvre pas la réponse réelle. Le navigateur applique aussi des règles à la réponse réelle. Testez OPTIONS puis réponse réelle, erreurs comprises. Un test qui vérifie seulement le 204 initial peut manquer un header absent ou une autorisation incorrecte sur l’opération réellement demandée.

Atelier guidé : lire, expliquer et vérifier le code

OPTIONS /lab/orders → 204
POST /lab/orders → 403

Le POST est refusé par une règle d’autorisation métier.

Le 204 d’OPTIONS décrit une étape de communication ; le 403 du POST exprime ensuite une décision de droit métier. Les deux résultats peuvent être corrects ensemble. Vérifiez que le POST interdit ne modifie rien et qu’un acteur autorisé peut réussir le même parcours.

Il ne donne pas ce privilège. Le précontrôle ne doit pas produire cet effet. Le contrôle d’objet reste nécessaire. Le partage protocolaire et le droit d’action sont deux décisions.

Travail pratique : Capturez une pré-vérification puis le POST réel de votre laboratoire. Changez ensuite la politique et observez la mise en cache.

Critères de correction : Comparez les journaux : aucun effet métier sur OPTIONS, validation et droits sur POST. Utilisez un contexte de navigateur neuf pour distinguer une règle active d’une permission encore mémorisée.