Lors du développement d’une application web, sécuriser les communications est essentiel. Les headers HTTP jouent un rôle important pour protéger les données et limiter les risques de sécurité. Dans cet article, nous passons en revue les principaux headers de sécurité à connaître.
Si vous développez une API et souhaitez tester la sécurité de vos headers HTTP (mais pas seulement), vous pouvez utiliser l’outil VulnAPI. C’est un outil gratuit qui permet de tester la sécurité de votre API, y compris celle de vos headers HTTP.
Que sont les headers de sécurité ?
Les headers de sécurité sont des headers de réponse HTTP qui indiquent au navigateur comment traiter la page web. Ils protègent votre application web contre diverses attaques, comme le cross-site scripting (XSS), le clickjacking et le content sniffing. En définissant des headers de sécurité, vous contrôlez la façon dont le navigateur interagit avec votre page et vous limitez les risques.
Les headers de sécurité essentiels
Content Security Policy (CSP)
Le header Content Security Policy (CSP) aide à prévenir les attaques de cross-site scripting (XSS) et d’injection de données en restreignant les sources depuis lesquelles des ressources peuvent être chargées sur une page web. Avec la CSP, vous définissez une liste blanche (allowlist) de sources de confiance pour les scripts, feuilles de style, images, polices et autres ressources. Ce header protège votre application web contre les scripts malveillants injectés par des attaquants.
Exemple de header CSP :
Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com;Se prémunir du clickjacking avec X-Frame-Options
Le header X-Frame-Options aide à prévenir les attaques de clickjacking en restreignant la façon dont votre page peut être intégrée dans une iframe. Grâce à lui, vous contrôlez si votre page peut être affichée dans un cadre sur un autre site. Cela protège votre application web des attaques de clickjacking qui piègent les utilisateurs pour leur faire effectuer des actions non souhaitées.
HTTP Strict Transport Security (HSTS)
Votre application web doit utiliser HTTPS pour garantir des échanges sécurisés entre le client et le serveur. Le header HTTP Strict Transport Security (HSTS) indique au navigateur de ne communiquer avec le serveur qu’en HTTPS, même si l’utilisateur saisit une URL en HTTP. Cela limite les attaques de type man-in-the-middle et garantit que toutes les communications sont chiffrées.
Cross-Origin Resource Sharing (CORS)
Sans doute le header de sécurité le plus connu, Cross-Origin Resource Sharing (CORS) vous permet de contrôler quelles ressources de votre serveur peuvent être appelées depuis d’autres domaines. En configurant les headers CORS, vous définissez les origines autorisées à effectuer des requêtes cross-origin vers votre serveur. Cela aide à prévenir les attaques cross-origin et protège les données sensibles contre l’accès par des domaines non autorisés.
Cache-Control pour les 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. Avec Cache-Control, vous précisez si le navigateur ou les proxies intermédiaires peuvent mettre en cache des ressources, pour combien de temps, et si elles peuvent être stockées dans des caches partagés.
Si vous servez des données sensibles, comme des informations utilisateur ou des jetons d’authentification, vous devez configurer le header Cache-Control pour empêcher la mise en cache et éviter que ces données ne soient stockées côté client ou dans des caches partagés.
Exemple de header Cache-Control :
Cache-Control: no-store, no-cache, must-revalidate, max-age=0Parlons des cookies
Les cookies servent à de nombreux usages : gestion de session, authentification des utilisateurs, suivi du comportement, etc. Mal gérés, ils peuvent toutefois présenter des risques de sécurité et permettre à des attaquants de réaliser du détournement de session (session hijacking), du cross-site scripting et d’autres attaques.
Pour sécuriser vos cookies, suivez ces bonnes pratiques :
- Flag Secure : activez le flag Secure sur les cookies pour qu’ils ne soient envoyés que via des connexions HTTPS. Cela empêche des attaquants de les intercepter sur des connexions non chiffrées.
- Flag HttpOnly : activez le flag HttpOnly sur les cookies pour empêcher les scripts côté client d’y accéder. Cela limite les attaques de cross-site scripting qui tentent de voler des cookies avec des scripts malveillants.
- Attribut SameSite : définissez l’attribut SameSite sur les cookies pour contrôler leur envoi dans les requêtes cross-site. En le positionnant à Strict ou Lax, vous prévenez les attaques de cross-site request forgery (CSRF) qui tentent de pousser les utilisateurs à effectuer des requêtes non autorisées.
Tester vos headers de sécurité
Pour vous assurer que votre application web est sécurisée, testez régulièrement vos headers de sécurité. Vous pouvez utiliser des outils comme Security Headers ou Mozilla Observatory pour analyser votre site et vérifier que les headers nécessaires sont correctement configurés.
Utiliser des tokens CSRF pour les soumissions de formulaires
Le Cross-Site Request Forgery (CSRF) est une attaque qui piège les utilisateurs pour leur faire exécuter des actions non souhaitées sur une application web où ils sont authentifiés. Pour s’en prémunir, utilisez des tokens CSRF dans vos formulaires web. Ces tokens sont des valeurs uniques générées pour chaque session utilisateur et soumises avec les données du formulaire. À la soumission, le serveur valide le token CSRF pour s’assurer que la requête est légitime.
La plupart des frameworks web modernes proposent une prise en charge native des tokens CSRF, ce qui facilite la mise en place de cette protection dans votre application.
Pensez au CAPTCHA
Le CAPTCHA, ces tests agaçants qui vous demandent d’identifier des feux tricolores ou des vélos dans une série d’images. Même s’ils peuvent être frustrants pour les utilisateurs, ils constituent un moyen efficace d’empêcher des bots automatisés de soumettre des formulaires sur votre site. En ajoutant des CAPTCHA à vos formulaires, vous réduisez le risque de soumissions de spam et protégez votre application des bots malveillants.
Aujourd’hui, il est possible d’utiliser un CAPTCHA invisible : l’utilisateur n’a aucun test à résoudre, et une analyse comportementale détermine s’il s’agit d’un humain ou d’un bot. Cela offre une expérience plus fluide tout en protégeant votre application contre les attaques automatisées.