En-têtes de sécurité HTTP (Security Headers) Cross-Origin Resource Sharing (CORS)

• Origines : Dans le contexte du CORS, une "origine" est définie par le protocole (HTTP ou HTTPS), le nom de domaine et le numéro de port d'un site web. Par exemple, http://www.example.com:80 et https://example.com:443 sont considérés comme deux origines différentes.

• Requêtes cross-origin : Par défaut, les navigateurs web appliquent la politique de même origine (Same-Origin Policy), ce qui signifie qu'une page web peut uniquement effectuer des requêtes vers des ressources situées sur la même origine que la page elle-même. Les requêtes vers des ressources situées sur des origines différentes sont bloquées pour des raisons de sécurité.

• CORS headers : Pour permettre explicitement les requêtes cross-origin, le serveur web peut inclure des en-têtes CORS dans ses réponses HTTP. Ces en-têtes CORS indiquent au navigateur si les requêtes cross-origin sont autorisées et quelles origines sont autorisées à accéder aux ressources. Les en-têtes CORS courants incluent Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, etc.

• Pré-vérifications : Pour certaines requêtes cross-origin considérées comme "privilégiées" (comme les requêtes avec des méthodes HTTP autres que GET, POST, HEAD, ou avec des en-têtes personnalisés), le navigateur effectue une pré-vérification OPTIONS avant de laisser la requête réelle être envoyée. Cela permet au serveur de spécifier les méthodes HTTP et les en-têtes qui sont autorisés pour cette origine particulière.

Quelles sont les risques ?

• Vulnérabilités CSRF (Cross-Site Request Forgery) : En l'absence de politiques CORS appropriées, un site malveillant pourrait effectuer des requêtes cross-origin depuis le navigateur d'un utilisateur authentifié sur un autre site. Cela pourrait entraîner des actions non autorisées, telles que la modification des paramètres de compte, la suppression de données ou la réalisation de transactions financières en nom de l'utilisateur.

• Exposition de données sensibles : Sans CORS, les ressources sensibles telles que les API REST, les bases de données ou les fichiers peuvent être accessibles à partir de domaines non autorisés. Cela pourrait permettre à des attaquants d'accéder à des informations confidentielles telles que des informations personnelles, des identifiants de session, des mots de passe ou d'autres données sensibles.

• Vulnérabilités XSS (Cross-Site Scripting) : Bien que CORS ne soit pas directement lié à la prévention des attaques XSS, son utilisation peut aider à limiter les risques en empêchant l'accès non autorisé aux ressources du site. Sans CORS, les attaquants pourraient potentiellement utiliser des attaques XSS pour accéder à des ressources cross-origin et voler des données sensibles.

• Fuite d'informations confidentielles : L'absence de politiques CORS appropriées peut entraîner la fuite d'informations sensibles telles que des données clients, des secrets d'entreprise ou des propriétés intellectuelles à des tiers non autorisés. Cela pourrait nuire à la réputation de l'entreprise, entraîner des pertes financières ou causer d'autres dommages.