13. CORS : autoriser une lecture sans ouvrir les droits

Comprendre le mécanisme

CORS fournit un protocole par lequel le serveur indique au navigateur quelles lectures interorigine sont permises. Il ne constitue pas une authentification de l’utilisateur ni une barrière universelle contre un client HTTP autonome. Réfléchir automatiquement toute valeur Origin reçue peut accorder une lecture à un appelant non prévu. Les règles doivent distinguer ressources publiques et réponses liées à une identité.

Raisonner et vérifier

Utilisez une liste d’origines complète et exacte pour les interfaces connues. Lorsque la réponse de politique varie selon Origin et peut être mise en cache, prenez en compte cette variation. Évaluez aussi les méthodes et champs permis, sans les élargir pour faire disparaître une erreur de console. Une API non accessible au navigateur d’un tiers peut rester directement joignable : elle garde ses contrôles d’accès.

Partage navigateur

CORS organise un partage de réponse avec le navigateur. La politique de lecture ne vérifie pas l’identité. Access-Control-Allow-Origin décrit un partage de réponse avec une origine de navigateur. Il ne bloque pas automatiquement un appel réseau direct effectué par un autre programme ou un serveur.

Admission explicite

Une liste d’origines doit être explicite et contrôlée. La valeur reçue n’établit pas sa légitimité. Comparez Origin à une liste maîtrisée et normalisée selon votre contrat. Refléter toute valeur revient à annoncer une confiance très large, particulièrement dangereuse pour des réponses personnelles.

Client autonome

Un client direct peut appeler l’API sans appliquer CORS. Les contrôles serveur demeurent indispensables. Un client hors navigateur n’a pas à appliquer CORS comme le ferait fetch dans une page. Exigez credentials et permissions indépendamment des headers CORS renvoyés par l’API.

Méthode et droit

Les méthodes admises ne donnent pas de permissions métier. La déclaration protocolaire ne crée pas ces droits. Autoriser POST dans le partage CORS ne donne pas à Alice le droit de modifier la réservation de Bob. Le serveur doit encore appliquer la décision métier après authentification.

Origin absent

Un Origin absent nécessite une politique adaptée au type de client. Les clients non navigateur peuvent suivre un autre contrat. Certains clients légitimes peuvent ne pas envoyer Origin. Définissez une politique selon vos types de clients sans transformer son absence en preuve d’authenticité ou en accès privilégié.

Test navigateur

Une origine refusée doit être testée dans le navigateur. Le trajet complet et le navigateur participent au résultat. Vérifiez une origine admise et une origine refusée avec un vrai navigateur. Un test de headers seul ne démontre pas la lisibilité effective de la réponse dans le contexte considéré.

Credentials

Les credentials imposent des contraintes de partage spécifiques. L’origine explicite est requise dans ce cas de partage. Une réponse personnelle avec credentials demande une origine explicitement admise et les règles de partage compatibles. Le joker ne doit pas servir de raccourci à une politique d’identités automatiques.

Erreurs cohérentes

Les erreurs d’API peuvent aussi nécessiter des en-têtes cohérents. Les réponses d’erreur participent à l’expérience et au contrat. Le frontend doit pouvoir traiter les erreurs que le contrat choisit de partager. Vérifiez les headers sur réponses d’échec aussi, sans ouvrir plus largement les données pour résoudre un simple message console.

Variation et cache

La clé de cache doit respecter les variations pertinentes d’origine. Un cache peut servir la mauvaise politique sans dimension adéquate. Si la réponse varie selon Origin, sa stratégie de cache doit respecter cette dimension. Sinon un intermédiaire peut réutiliser une réponse ou ses permissions pour une autre origine.

Droits après identité

L’autorisation sur l’objet doit suivre l’authentification. La politique CORS ne supprime pas l’isolation métier. Un cookie ou bearer token valide identifie un acteur selon son mécanisme. Vérifiez ensuite l’accès à la ressource ; CORS ne porte aucune preuve de propriété métier.

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

Access-Control-Allow-Origin: https://portal.example.test

Client considéré : script HTTP serveur, hors navigateur.

Le client considéré est un script serveur et non une page de navigateur. Le header CORS ne constitue donc pas sa barrière d’admission réseau. Ajoutez une authentification et un contrôle de ressource effectifs, puis utilisez un navigateur pour vérifier séparément la politique de partage annoncée.

CORS définit un partage pour le navigateur, pas toute admission réseau. Un client direct ne suit pas nécessairement cette politique. Un nom d’origine ne définit pas les permissions. Le modèle du navigateur n’est pas celui de tout client serveur.

Travail pratique : Écrivez une matrice CORS pour une ressource publique et une ressource personnelle, avec une origine admise et une origine refusée.

Critères de correction : Vérifiez les réponses réelles et le comportement du navigateur. Répétez avec un client HTTP sans politique navigateur pour confirmer que l’autorisation métier reste appliquée indépendamment des champs CORS.