Les applications web modernes accèdent généralement à des API s'exécutant sur des domaines, sous-domaines ou ports différents. Le navigateur restreint cet accès via la politique CORS. Si une API ne retourne pas les headers Access-Control-Allow-* corrects, la requête est bloquée par le navigateur même si elle s'exécute avec succès côté serveur. Le résultat est une application cassée pour l'utilisateur et une erreur CORS difficile à diagnostiquer pour l'équipe.
Dans la plupart des organisations, ce problème est distribué aux équipes applicatives. Chaque service définit séparément son comportement Origin, Method, Header, Credentials et Max-Age dans ses propres paramètres de framework. À mesure que le nombre de services augmente, il devient inévitable que la même politique CORS se retrouve écrite différemment selon les applications.
Des paramètres CORS incorrects créent également des risques de sécurité. Pendant le développement, des Origins wildcard sont ouvertes comme solution rapide, des permissions trop larges sont accordées avec les credentials, ou le comportement preflight est laissé incomplet. Quand de tels paramètres atteignent la production, la surface API est inutilement exposée.
La bonne approche est de gérer la politique CORS comme une règle de réponse/requête centrale. La liste blanche d'origines, les credentials, les méthodes autorisées, les headers autorisés et le cache preflight doivent tous être définis en un seul endroit et ne pas être dispersés dans le code applicatif.
La Règle de Politique CORS TR7 délivre ce modèle : elle rend les headers CORS preflight et de réponse réelle gérables depuis une seule action, au niveau du vService ou du path.
La politique CORS TR7 regroupe la validation d'origine, la gestion preflight, les headers de réponse et la logique d'application conditionnelle sous une seule règle.
TR7 peut comparer la valeur Origin entrante à une liste blanche définie. La liste peut contenir des domaines fixes ou des correspondances regex plus flexibles.
TR7 peut générer les headers CORS requis pour les requêtes OPTIONS preflight. Cela permet à l'application de se concentrer uniquement sur la vraie requête API.
Des headers tels que Access-Control-Allow-Origin, Allow-Methods, Allow-Headers, Allow-Credentials et Max-Age sont ajoutés via la politique centrale. La compatibilité navigateur devient indépendante du code applicatif.
Différentes surfaces API sur le même équipement peuvent opérer avec un comportement CORS différent. L'API publique peut être plus large, l'API partenaire plus étroite et l'API interne gérée avec sa propre liste blanche.
La Règle de Politique CORS simplifie le processus de publication des API en fournissant la gestion preflight et de réponse réelle depuis une seule action.
L'action CORS TR7 peut gérer à la fois les requêtes OPTIONS preflight et les headers de réponse API réelle sous la même politique. Cela empêche les équipes applicatives de coder séparément les comportements preflight et de réponse réelle. La politique est définie une fois et appliquée au vService ou path concerné. Les opérations peuvent gérer le comportement CORS de manière centralisée.
Les valeurs Origin autorisées peuvent être définies explicitement dans la politique CORS. Cette liste peut être composée de domaines spécifiques, de patterns de sous-domaines ou de correspondances regex. L'accès est accordé aux applications frontend de confiance sans être contraint d'utiliser des wildcards. L'accès navigateur est fourni sans exposer inutilement la surface API à des sources indésirables.
Les organisations utilisent fréquemment des structures de sous-domaines basées sur les clients, tenants ou environnements. La correspondance d'origine basée sur regex permet d'établir une politique d'autorisation contrôlée sans écrire chaque sous-domaine individuellement. Par exemple, les frontends de tenants sous un arbre de domaine spécifique peuvent être acceptés. Cette flexibilité permet une gestion CORS évolutive sans ouvrir des wildcards.
Le comportement Access-Control-Allow-Credentials peut être activé/désactivé de manière centralisée. Ce paramètre est critique pour les frontends qui fonctionnent avec des cookies ou des headers d'autorisation. Quand les credentials sont activés, la liste blanche d'origines doit être maintenue étroite. TR7 déplace ce comportement des paramètres dispersés des équipes applicatives vers un point de politique unique.
Des méthodes telles que GET, POST, PUT, PATCH, DELETE ou OPTIONS peuvent être définies dans la politique. Le navigateur n'accepte que les méthodes autorisées lors du preflight. Cela clarifie quels types d'opérations l'API expose côté client. La sécurité et l'expérience développeur sont gérées depuis la même liste.
Authorization, Content-Type, X-Request-ID ou des headers applicatifs personnalisés peuvent être définis dans la liste blanche. Le navigateur vérifie lors d'une requête preflight si ces headers peuvent être utilisés. Les permissions de headers manquantes conduisent à des erreurs frontend ; des permissions de headers trop larges créent une exposition de surface inutile. TR7 gère cet équilibre de manière centralisée.
La valeur Access-Control-Max-Age contrôle combien de temps le navigateur met en cache le résultat du preflight. Une valeur max-age appropriée réduit le trafic OPTIONS pour les appels API fréquents. Une valeur trop courte crée une surcharge preflight inutile ; une valeur trop longue signifie que les changements de politique peuvent être reflétés tardivement. TR7 rend ce paramètre configurable selon les besoins du service.
Chaque vService peut avoir sa propre politique CORS. L'API publique, l'API partenaire, l'API admin ou l'API interne peuvent opérer avec des listes d'origines et de méthodes différentes. Ce modèle empêche qu'un seul paramètre CORS global soit appliqué trop largement à toutes les API. L'opérateur établit des frontières de sécurité par service.
Différentes politiques CORS peuvent être appliquées à différents paths au sein du même vService. Par exemple, `/public/api` peut opérer avec une liste d'origines plus large tandis que `/admin/api` opère uniquement avec un frontend de gestion spécifique. Cela sépare la surface API au niveau de l'endpoint. Il n'est pas nécessaire d'écrire des blocs if CORS complexes dans le code applicatif.
L'action CORS peut être utilisée dans le cadre du moteur de règles de trafic. Les headers CORS peuvent être appliqués en fonction du host, du path, du header, de la méthode ou d'autres conditions. Cela permet de gérer de nombreux modèles de publication différents sur un seul équipement. La politique CORS devient une règle de trafic contextuelle plutôt qu'un paramètre statique.
Quand le comportement CORS est distribué à travers les frameworks applicatifs, chaque langage et service nécessite une logique de configuration différente. TR7 déplace ce comportement vers la couche ADC, réduisant la dépendance applicative. Les équipes applicatives se concentrent uniquement sur la logique métier API tandis que le standard CORS est maintenu de manière centralisée. Les services legacy et modernes peuvent être publiés sous le même modèle de politique.
Quand la politique CORS est modifiée dans la configuration centrale, elle peut être incluse dans les processus d'audit et de rollback. Les questions de qui a ouvert quelle origine, quelle méthode ou quel comportement de credentials peuvent être suivies. C'est particulièrement important lors des revues de sécurité. La gestion CORS auditable remplace les paramètres applicatifs dispersés.
La Règle de Politique CORS est opérée conjointement avec la correspondance d'origine, le comportement des credentials, la réponse preflight, l'équilibre max-age, le périmètre de path et la visibilité d'audit.
La valeur Origin entrante peut être comparée à une liste blanche ou à des règles regex. En l'absence de correspondance, les headers CORS peuvent ne pas être ajoutés, ou un comportement de rejet peut être appliqué selon la politique. L'utilisation d'une liste explicite plutôt qu'un wildcard est recommandée.
Quand les credentials sont actifs, des informations d'identité telles que les cookies et les headers auth peuvent être utilisées dans les requêtes cross-origin. Dans ce mode, il est important que la politique Origin soit étroite et bien définie. Les credentials avec une Origin wildcard ne constituent pas une configuration sécurisée.
Les requêtes OPTIONS sont envoyées par le navigateur pour vérifier les permissions de méthodes et headers. TR7 peut gérer centralement la réponse preflight en générant les headers Allow-* requis. Cela réduit la charge sur le service backend liée aux requêtes OPTIONS inutiles.
La durée du cache preflight nécessite un équilibre entre la performance et la fraîcheur de la politique. Une durée plus longue produit moins de requêtes OPTIONS, mais les changements CORS peuvent être ressentis tardivement à cause du cache navigateur. Cette valeur doit être choisie soigneusement pour les API critiques.
La politique CORS peut être liée à des conditions de path ou host spécifiques. Cela permet d'appliquer un comportement CORS différent à différentes surfaces API au sein du même vService. Les endpoints admin et les endpoints publics n'ont pas besoin de partager les mêmes permissions.
Les changements de politique CORS peuvent être suivis dans la configuration centrale et le processus d'audit. Les changements de la liste d'origines ou du comportement des credentials doivent être considérés comme significatifs pour la sécurité. L'historique des changements a de la valeur pour le rollback et la conformité.
Quand une application frontend accède à une API sur un domaine différent, le navigateur peut recevoir une erreur CORS. L'ajout de la politique correcte d'origine, de méthode et de header via TR7 résout le problème de manière centralisée.
Dans un environnement SaaS, chaque tenant peut exécuter son propre frontend sur un sous-domaine dédié. Une liste blanche supportant les regex accepte l'ensemble de l'arbre de domaines tenant de manière contrôlée.
Les applications partenaires peuvent accéder à l'API uniquement avec des origines spécifiques et des headers d'autorisation. La règle CORS TR7 définit ces permissions de manière centralisée et ferme la surface de headers et méthodes inutile.
Des cookies cross-origin peuvent être nécessaires dans les flux SSO ou de fédération. TR7 place ce comportement sous contrôle avec le toggle credentials et une liste d'origines étroite.
Au sein du même vService, l'endpoint public peut opérer avec une politique plus large et l'endpoint admin avec une politique plus étroite. Cette séparation est appliquée via une règle de trafic sans l'écrire dans le code applicatif.
Gérez preflight, headers de réponse, liste blanche d'origines et comportement des credentials depuis une seule règle ADC. Parcourons ensemble une configuration en direct sur vos propres services.