Que sont les en-têtes de sécurité HTTP et comment les utilisez-vous ?

Des lecteurs comme vous aident à soutenir MUO. Lorsque vous effectuez un achat en utilisant des liens sur notre site, nous pouvons gagner une commission d'affiliation.

Lorsque vous souhaitez visiter un site Web, le navigateur Internet que vous utilisez reçoit certaines données de ce site. En conséquence, un dialogue s'établit entre votre appareil et le site Web. Cela se produit avec le protocole appelé HTTP. Il est possible de prendre des mesures de sécurité supplémentaires en intervenant dans ce dialogue.

UTILISEZ LA VIDÉO DU JOUR

Si vous exploitez un site Web ou si vous visez une carrière de développeur Web, les en-têtes de sécurité HTTP sont inestimables pour vous, car ils jouent un rôle actif dans la sécurité de l'utilisateur et du site Web.

Qu'est-ce que HTTP Strict-Transport-Security (HSTS) ?

HTTP Strict Transport Security (HSTS) oblige les utilisateurs à utiliser HTTPS pour chaque requête qu'ils effectuent dans leur navigateur. C'est un moyen solide de lutter contre les cyberattaques comme les déclassements et d'assurer la sécurité de tout le trafic.

L'activation du HSTS est assez simple. Considérez le dialogue entre le client et le serveur. Lorsque vous essayez d'accéder à un site via votre navigateur, vous êtes le client. Le site que vous souhaitez ouvrir dépend du serveur. Votre but est de dire au serveur 'Je veux ouvrir ce site'. Il s'agit d'une opération de requête. Le serveur, quant à lui, vous dirige vers le site si vous remplissez les conditions souhaitées.

Gardez cela à l'esprit en ce qui concerne cet exemple d'indicateur d'en-tête HTTP :

Strict-Transport-Security: max-age=16070200;

Lorsque vous ajoutez cet indicateur aux informations d'en-tête de la réponse HTTP, toutes les demandes générées par l'utilisateur deviendront HTTPS. Quoi que l'utilisateur écrive ici, le navigateur évaluera automatiquement le protocole comme HTTPS et établira une connexion sécurisée.

Comment utiliser le HSTS

Au lieu d'ajouter toutes ces informations d'en-tête HTTP dans la couche de code, vous pouvez le faire sur Apache, IIS, Nginx, Tomcat et d'autres applications de serveur Web.

Pour activer HSTS dans Apache :

LoadModule headers_module modules/mod_headers.so 
<VirtualHost *:443> 
    Header always set Strict-Transport-Security "max-age=2592000; includeSubDomains" 
</VirtualHost>

Pour activer HSTS dans Nginx :

add_header Strict-Transport-Security max-age=2592000; includeSubdomains

Pour activer HSTS avec IIS web.config :

<system.webServer> 
   <httpProtocol> 
       <customHeaders> 
           <add name="Strict-Transport-Security" value="max-age=63072000"/> 
       </customHeaders> 
   </httpProtocol> 
</system.webServer>

Pour les utilisateurs de Cloudflare

Cloudflare fournit un service HTTPS gratuit pour tout le monde avec son service SSL sans clé ; avant de faire une demande de préchargement HSTS, vous devez savoir que votre certificat ne vous appartient pas. De nombreux sites utilisent des certificats SSL car ils constituent un moyen simple de sécuriser les données.

Cependant, Cloudflare maintenant prend en charge la fonction HSTS . Vous pouvez activer toutes les fonctionnalités HSTS, y compris le préchargement, via l'interface Web Cloudflare sans vous débattre avec les configurations sur le serveur Web.

Qu'est-ce que X-Frame-Options ?

Augmenter la sécurité du site Web avec des en-têtes HTTP

X-Frame-Options est un en-tête de sécurité pris en charge par tous les navigateurs modernes. X-Frame-Options vise à protéger contre le vol de clics tel que le Clickjacking. Comme son nom l'indique, il s'agit du fonctionnement d'un cadre en ligne vulnérable, également appelé iframe. Il s'agit d'éléments d'un site qui intègrent une autre page HTML dans le site « parent », de sorte que vous pouvez utiliser le contenu d'autres sources sur votre site. Mais les attaquants utilisent des iframes sous leur propre contrôle pour obliger les utilisateurs à effectuer des actions qu'ils ne souhaitent pas.

Pour cette raison, vous devez empêcher les attaquants de trouver des iframes sur le site.

Où et comment utiliser les options X-Frame ?

Ce que fait X-Frame-Options, certains développeurs essaient de le faire avec des langages comme JavaScript. Ce n'est pas tout à fait faux. Cependant, il existe toujours un risque car les codes écrits sous de nombreux aspects ne suffisent pas. Il serait donc sage de laisser cette tâche au navigateur Internet que vous utilisez.

Cependant, en tant que développeur, il y a trois paramètres à connaître sur X-Frame-Options :

Refuser : Empêche complètement l'appel de la page dans n'importe quel iframe.
SAMEORIGINE : Empêcher tout domaine autre que le vôtre d'appeler dans l'iframe.
ALLOW-FROM uri : Accepte les appels iframe de l'URI donné en paramètre. Bloquez les autres.

Ici le SAMEORIGINE caractéristique se démarque davantage. Parce que même si vous pouvez appeler des applications dans vos différents sous-domaines avec des iframes les unes dans les autres, vous pouvez empêcher qu'elles soient appelées sur le domaine sous le contrôle de l'attaquant.

comment faire une image transparente

Voici des exemples d'utilisation de SAMEORIGIN et X-Frame-Options avec NGINX, Apache et IIS :

Utilisation des options X-Frame SAMEORIGIN pour Nginx :

add_header X-Frame-Options SAMEORIGIN;

Utilisation de X-Frame-Options SAMEORIGIN pour Apache :

Header always append X-Frame-Options SAMEORIGIN

Utilisation des options X-Frame SAMEORIGIN pour IIS :

<httpProtocol> 
   <customHeaders> 
     <add name="X-Frame-Options" value="SAMEORIGIN" /> 
   </customHeaders> 
 </httpProtocol>

Le simple fait d'ajouter l'en-tête SAMEORIGIN seul apportera une plus grande sécurité à vos visiteurs.

Qu'est-ce que la protection X-XSS ?

L'utilisation des informations d'en-tête X-XSS-Protection peut protéger les utilisateurs contre les attaques XSS. Tout d'abord, vous devez éliminer Vulnérabilités XSS du côté des applications. Après avoir fourni une sécurité basée sur le code, d'autres mesures, c'est-à-dire des en-têtes X-XSS-Protection, sont nécessaires contre les vulnérabilités XSS dans les navigateurs.

Windows, vous avez besoin d'une autorisation pour effectuer cette action

Comment utiliser X-XSS-Protection

Les navigateurs modernes peuvent détecter les charges utiles XSS potentielles en filtrant le contenu généré par l'application. Il est possible d'activer cette fonctionnalité avec les informations d'en-tête X-XSS-Protection.

Pour activer l'en-tête X-XSS-Protection dans Nginx :

add_header X-Frame-X-XSS-Protection 1;

Pour activer l'en-tête X-XSS-Protection dans Apache :

Header always append X-XSS-Protection 1

Pour activer l'en-tête X-XSS-Protection dans IIS :

<httpProtocol> 
   <customHeaders> 
     <add name="X-XSS-Protection" value="1" /> 
   </customHeaders> 
 </httpProtocol>

Pour empêcher le bloc de code avec l'attaque XSS par défaut de s'exécuter, vous pouvez utiliser quelque chose comme ceci :

X-XSS-Protection: 1; mode=block

Cette modification mineure doit être apportée s'il existe une situation potentiellement dangereuse et que vous souhaitez empêcher l'affichage de tout le contenu.

Qu'est-ce que X-Content-Type-Options ?

Les navigateurs effectuent une analyse appelée MIME Type Sniffing sur le contenu qui leur est présenté par l'application Web. Par exemple, s'il y a une demande d'accès à un fichier PDF ou un fichier PNG, les navigateurs qui effectuent une analyse sur la réponse HTTP en déduisent le type de fichier.

Considérez un fichier avec une extension jpeg mais qui a en fait un contenu Texte/HTML. Après avoir utilisé les extensions et passé les protections dans le module de téléchargement, le fichier est téléchargé avec succès. Le fichier téléchargé est appelé via l'URL et le reniflage de type MIME renvoie du texte/HTML en conséquence. Il rend le contenu au format HTML. C'est alors que la vulnérabilité XSS se produit.

Vous devez donc empêcher les navigateurs de décider du contenu en reniflant le type MIME. Pour ce faire, vous pouvez utiliser nosniff.

En-tête X-Content-Type-Options pour Nginx :

add_header X-Content-Type-Options nosniff;

En-tête X-Content-Type-Options pour Apache :

Header always X-Content-Type-Options nosniff

En-tête X-Content-Type-Options pour IIS :

<httpProtocol> 
   <customHeaders> 
     <add name="X-Content-Type-Options" value="nosniff" /> 
   </customHeaders> 
 </httpProtocol>

Les applications Web suivent les sessions des utilisateurs via l'ID de session. Les navigateurs le stockeront et l'ajouteront automatiquement à chaque requête HTTP dans le champ d'application du cookie.

C'est possible utiliser des cookies à des fins autre que le transfert de la clé de session, cependant. Les pirates pourraient découvrir les données des utilisateurs en utilisant la vulnérabilité XSS susmentionnée ou via une attaque Cross-Site Request Forgery (CSRF). Alors, quels cookies sont les plus importants en termes de sécurité ?

Vous pouvez considérer les informations contenues dans la dernière image sur laquelle vous avez cliqué dans la galerie d'images à titre d'exemple. De cette façon, le trafic HTTP est moindre et une partie de la charge peut être résolue par le navigateur Internet de l'utilisateur avec des scripts côté client.

Utilisation d'en-têtes HTTP pour protéger les informations confidentielles sur le site

C'est là que HttpOnly Voici un exemple de la façon dont l'attribution des cookies devrait être :

Set-Cookie: user=t=cdabe8a1c2153d726; path=/; HttpOnly

Notez la valeur HttpOnly envoyée dans le Set-Cookie opération. Le navigateur le verra et ne traitera pas les valeurs avec l'indicateur HttpOnly lorsque le cookie est accessible via le document.cookie variable. Un autre drapeau utilisé dans le processus Set-Cookie est le drapeau Secure. Cela indique que la valeur du cookie sera ajoutée à l'en-tête uniquement pour les requêtes HTTPS. Les sites de commerce électronique l'utilisent généralement parce qu'ils souhaitent réduire le trafic réseau et augmenter les performances.

En utilisant cette méthode, vous pouvez masquer les données critiques des utilisateurs telles que les noms d'utilisateur, les mots de passe et les informations de carte de crédit. Mais il y a un problème. Les utilisateurs qui terminent le processus de connexion se voient attribuer une valeur de cookie sans l'indicateur Secure. L'utilisateur peut disposer de la clé de session lorsqu'il effectue une requête HTTP vers des liens non HTTPS. L'ajout du drapeau sécurisé est simple :

Set-Cookie: user=t=cdabe8a1c2153d726; path=/; Secure

Quand ne devriez-vous pas utiliser HttpOnly ? Si vous comptez sur Javascript, vous devez vous méfier car cela peut rendre votre site moins sécurisé.

De petites étapes fonctionnent pour une sécurité Web plus large

Vous n'avez pas besoin de connaissances avancées en matière de logiciels et de serveurs pour augmenter la sécurité des applications Web. En changeant seulement quelques lignes, vous pouvez prévenir certaines attaques sérieuses. Bien sûr, cela ne suffit pas. Cependant, il s'agit d'une étape modeste mais efficace pour la sécurité du site Web. La connaissance est la meilleure prévention, il est donc également utile de connaître les nuances subtiles de la façon dont HTTPS protège les données pendant le transfert.