Quelques entêtes HTTP pour sécuriser (un peu) votre site

10 octobre 2023, par Didier Sampaolo

La sécurité, ça doit être un souci permanent, qui demande des efforts constants pour rester au niveau. Dans cet article, on va parler de quelques headers HTTP à configurer sur votre serveur pour avoir une première couche de sécurité sans trop vous compliquer la vie.

Tout au long de cet article, je vais partir du principe que vous utilisez nginx et que vous savez vous servir d'un éditeur de texte (comme nano ou vim).

Pour rappel, voici commande bash pour vérifier que votre configuration Nginx est correcte, et si oui, recharger la config de nginx :

sudo nginx -t && sudo systemctl reload nginx

HSTS + Preload

L'en-tête HTTP Strict-Transport-Security (HSTS) force les navigateurs à utiliser des connexions sécurisées (HTTPS). La directive preload permet une inclusion anticipée de votre domaine dans les listes HSTS des navigateurs, assurant ainsi une connexion sécurisée dès la première requête.

La mise en place de l'en-tête HSTS avec la directive preload sur Nginx est une étape importante pour renforcer la sécurité de votre site web. Assurez-vous de comprendre les implications, notamment que le retrait d'un domaine de la liste de préchargement peut prendre du temps.

L'implémentation de l'en-tête HSTS avec la directive preload engendre un engagement fort en faveur du HTTPS, difficile à révoquer. Une fois votre domaine sur la liste de préchargement, le retrait est long et compliqué, pouvant durer des mois, rendant tout retour vers HTTP extrêmement complexe. Si votre certificat SSL/TLS expire ou présente des problèmes, votre site devient inaccessible, avec un impact négatif sur l'expérience utilisateur et potentiellement sur votre référencement. À ne pas prendre à la légère !

Mise en place du HSTS + Preload

Dans le bloc server, ajoutez la ligne suivante :

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

  • max-age spécifie la durée (en secondes) pendant laquelle le navigateur doit se souvenir que le site doit être accédé uniquement via HTTPS.
  • includeSubDomains indique que la politique s'applique également à tous les sous-domaines.
  • preload signale votre consentement à inclure votre domaine dans les listes de préchargement HSTS des navigateurs.

Après avoir redémarré/reload votre serveur nginx, allez sur HSTS Preload, vérifiez que votre site répond aux exigences de préchargement HSTS, et soumettez-le à la liste.

X-Content-Type-Options

L'en-tête X-Content-Type-Options est une mesure de sécurité qui peut être utilisée pour réduire le risque d'attaques basées sur le mime sniffing. Le mime sniffing se produit lorsque le navigateur web tente de déterminer le type MIME (type de média) des réponses HTTP, ce qui peut être exploité par des attaquants pour exécuter du code malveillant sur votre site web.

Mise en place de X-Content-Type-Options

Dans le bloc server, ajoutez la ligne suivante :

add_header X-Content-Type-Options "nosniff" always;

X-Frame-Options

L'en-tête X-Frame-Options est une mesure de sécurité importante qui aide à protéger votre site web contre les attaques de type "clickjacking". Les attaques de clickjacking se produisent lorsqu'un attaquant utilise un iframe transparent pour superposer un site web légitime avec un site web malveillant, trompant ainsi l'utilisateur pour qu'il clique sur des éléments du site malveillant tout en pensant qu'il interagit avec le site légitime.

Mise en place de X-Frame-Options

Dans le bloc server, ajoutez la ligne suivante pour refuser toutes les tentatives d'affichage de votre site via un iframe :

add_header X-Frame-Options "DENY" always;

Ou, si vous souhaitez autoriser l'affichage via un iframe uniquement sur votre propre site :

add_header X-Frame-Options "SAMEORIGIN" always;

Content-Security-Policy

L'en-tête Content-Security-Policy (CSP) est une mesure de sécurité robuste qui aide à mitiger les risques d'attaques de cross-site scripting (XSS) et d'autres types d'injections de code. Il permet aux administrateurs de spécifier quelles sources de contenu sont fiables, réduisant ainsi les vecteurs d'attaque possibles sur le site web.

La mise en place d'une politique CSP stricte peut causer des problèmes de compatibilité avec certains plugins ou bibliothèques JavaScript, donc assurez-vous de tester votre site web en profondeur après avoir appliqué ces modifications.

Mise en place de Content-Security-Policy

Dans le bloc server, ajoutez la ligne suivante pour définir la politique de sécurité du contenu. Dans cet exemple, nous autorisons le contenu uniquement de notre propre domaine et de sources HTTPS sûres, tout en désactivant l'exécution des scripts inline et l'évaluation de scripts :

add_header Content-Security-Policy "default-src 'self' https:; script-src 'self' https: 'unsafe-inline' 'unsafe-eval';" always;

La directive Content-Security-Policy doit être personnalisée en fonction des besoins spécifiques de votre site. Quelques exemples :

Pour autoriser les scripts provenant de domaines spécifiques :

script-src 'self' https://example.com;

Pour autoriser le chargement d'images de n'importe quel domaine :

img-src *;

Pour autoriser uniquement le chargement de médias (audio et vidéo) de votre propre domaine :

media-src 'self';