Lors de l’implémentation d’OpenID Connect (OIDC), sécuriser les communications est essentiel. Les headers HTTP sont souvent négligés alors qu’ils jouent un rôle important pour protéger les données et réduire les risques de sécurité. Dans cet article, nous passons en revue les principaux headers de sécurité à connaître.
Comme l’implémentation d’un OpenID Connect Provider ne diffère pas beaucoup de celle d’une application web classique, vous pouvez aussi lire notre article sur les headers de sécurité essentiels pour les applications web.
Concentrons-nous maintenant sur les headers de sécurité indispensables pour une implémentation OpenID Connect.
Avez-vous vraiment besoin des iframes ?
Si vous utilisez OpenID Connect pour une SPA, vous utilisez peut-être des iframes pour gérer l’authentification silencieuse. En revanche, si vous n’en utilisez pas, vous pouvez ajouter le header X-Frame-Options pour protéger votre provider contre les attaques de clickjacking. Ce header restreint la manière dont votre page peut être intégrée dans une iframe et protège votre application contre le clickjacking.
Cross-Origin Resource Sharing (CORS)
Avec OpenID Connect, vous pouvez avoir besoin d’effectuer des requêtes cross-origin vers le serveur d’autorisation. Pour contrôler quelles ressources de votre serveur sont accessibles depuis d’autres domaines, vous pouvez configurer les headers Cross-Origin Resource Sharing (CORS). En définissant les origines autorisées à effectuer des requêtes cross-origin vers votre serveur, vous prévenez les attaques cross-origin et protégez les données sensibles contre les domaines non autorisés.
Sauf si vous exploitez un OpenID Connect Provider public, vous connaissez les origines autorisées à interroger votre serveur. Vous pouvez donc définir le header Access-Control-Allow-Origin pour préciser les origines autorisées à y accéder.
Surveillez votre cache
Avec OpenID Connect, faites attention à la mise en cache des données sensibles. Le header Cache-Control vous permet de contrôler la façon dont le navigateur met en cache les ressources de votre page. En le configurant, vous précisez si le navigateur ou les proxies intermédiaires peuvent mettre en cache les ressources, pendant combien de temps, et si elles peuvent être stockées dans des caches partagés.
Il arrive que des proxies intermédiaires ou un CDN soient placés devant l’OpenID Connect Provider. Vous devez alors vous assurer que ces composants respectent le header Cache-Control que vous définissez. Pour diverses raisons (le plus souvent un manque de configuration ou une configuration paresseuse), ils peuvent ignorer ce header et mettre en cache beaucoup de choses pour améliorer les performances. Or, mettre en cache certains endpoints de l’OP provoque des problèmes de sécurité et des comportements incorrects. Un exemple typique est la mise en cache de l’endpoint userinfo, qui contient des informations sur l’utilisateur.
Les cookies de l’OpenID Connect Provider
Avec OpenID Connect, le provider peut utiliser des cookies pour stocker des informations de session ou des tokens. Vous devez vous assurer que ces cookies sont sécurisés et disposent des bons attributs. Par exemple, l’attribut Secure garantit que le cookie n’est envoyé que sur des connexions HTTPS, et l’attribut HttpOnly empêche les scripts côté client d’y accéder.
Évitez de partager ces cookies avec d’autres applications en définissant l’attribut SameSite à Strict ou Lax. Le cookie ne sera alors pas envoyé dans les requêtes cross-site, ce qui réduit le risque d’attaques de type cross-site request forgery (CSRF).
Si ce n’est pas le cas, vous devriez héberger votre OpenID Connect Provider sur un sous-domaine différent de celui de votre application, pour éviter de partager les cookies entre les deux et réduire le nombre de vecteurs d’attaque. Un OP est généralement un composant critique, bien sécurisé et bien surveillé, mais une application non maintenue hébergée sur le même domaine peut constituer une faille de sécurité, d’autant plus facilement exploitable si elle a accès aux cookies de l’OP.