Améliorer la sécurité avec des entêtes HTTP

Au départ, je voulais simplement ajouter un entête HTTP dans mon .htaccess pour refuser explicitement Google FLoC1 : 

Header always set Permissions-Policy: interest-cohort=()

J’ai compris en creusant le sujet que je pouvais ajouter d’autres entêtes HTTP assez facilement pour améliorer un peu plus significativement la sécurité des sites que j’héberge. Je me suis donc prise au jeu.

Si vous êtes comme moi, totalement novice dans ce domaine, je vous recommande de vous appuyer sur la synthèse proposée par Mozilla, Web Security Cheat Sheet.

Pour vérifier ma configuration, j’ai utilisé Mozilla Observatory. C’est un outil très pédagogique. Le site est scanné. On obtient une note, accompagnée de recommandations de correction.

Vous trouverez ci-dessous ce que j’ai pu mettre en place sur mon hébergement mutualisé (serveur Apache). Ne recopiez pas les exemples de configuration sans avoir lu la documentation d’abord (RTMF) !

HTTP Strict Transport Security (HSTS)

HSTS permet de forcer une connexion sécurisée sur les sites qui supportent https.

Monarobase installe automatiquement des certificats Let's Encrypt sur tous mes domaines et sous-domaines. A priori, c’est désormais chose courante sur les différents hébergeurs mutualisés, ça ne devrait donc pas être un problème pour la majorité des sites.

Redirection http vers https

Attention à effectuer au préalable une redirection http vers https.

Forcer la redirection HTTPS dans cPanel

Aller dans le volet Domaines et cocher l’option Force HTTPS Redirect.

Si vous gérez d’autres domaines, comme c’est mon cas, il faut gérer ça directement dans chaque fichier .htaccess. J’utilise : 

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Mise en place

J’ai suivi la recommandation du site HSTS Preload List Submission : 

Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

J’en ai profité pour ajouter mon domaine carevic.eu à la liste des domaines qui se préchargent automatiquement en https2.

Pour deux autres de mes domaines, j’avais le warning suivant, Warning: Unnecessary HSTS header over HTTP.

Pour corriger ça, j’ai rajouté "expr=%{HTTPS} == 'on'" à la place de la variable env=HTTPS3 qui est citée dans la plupart des résultats.

Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" "expr=%{HTTPS} == 'on'"

Divers X

Je regroupe ici X-Content-Type-Options, X-Frame-Options, et X-XSS-Protection. Ces trois entêtes servent à limiter les risques d’attaques XSS.

Header always set X-Content-Type-Options: nosniff
Header always set X-Frame-Options "DENY"
Header set X-XSS-Protection "1; mode=block"
  1. X-Content-Type-Options empêche les navigateurs d’interpréter comme tels des contenus qui ne sont pas des scripts ou des feuilles de style.
  2. X-Frame-Options interdit d’encapsuler le site dans une iframe.
  3. X-XSS-Protection arrête le chargement d’une page par le navigateur si celui-ci détecte une attaque XSS.

À noter que les deux dernières entêtes sont redondantes et pourraient être remplacées par Content Security Policy (CSP). Il est néanmoins conseillé de les laisser pour les vieux navigateurs.

Referrer Policy

Cet entête permet de limiter les informations relatives au référent (referrer). J’ai hésité entre no-referrer et strict-origin-when-cross-origin ; je me suis décidée pour la seconde option qui me semble être un bon compromis.

Header always set Referrer-Policy: strict-origin-when-cross-origin

Les exemples de la documentation sont explicites. Depuis la page https://luce.carevic.eu/fr/notes :

  1. Si je navigue vers une autre page du site luce.carevic.eu, le référent sera : https://luce.carevic.eu/fr/notes.
  2. Si je navigue vers un autre site https, le référent sera : https://luce.carevic.eu/
  3. Si je navigue vers un autre site http, il n’y aura pas de référent.

CSP, ça semble passionnant, mais c’est (super) pénible

Après avoir fait tout ce qui est simple, il faut s’attaquer à CSP et Subresource Integrity (SRI). Pour le second, comme je n’utilise aucun contenu hébergé par des services tiers, je peux m’en passer4.

Reste CSP… Le principe est passionnant. Tout ce qui n’est pas autorisé explicitement est interdit. En pratique, ça me paraît assez casse-pied de mettre en place des règles sécurisées, sans maîtriser de bout en bout le code et contenu de son site.

Ça demande bien plus de travail et de réflexion que les précédents entêtes. Le tout doit être progressif, en veillant bien à ne rien casser.

Pour l’instant, j’ai ajouté quelque chose de basique (et donc insuffisamment sécurisé), n’ayant pas le courage de m’y pencher plus en détail. Lire les rapports d’erreur et démêler le tout n’est pas ma définition du fun.

Effet de bord que j’avais remarqué avec des sites dont la CSP est bien ficelée, certains bookmarklets et extensions que j’utilise pour faire des audits d’accessibilité cassent sur Firefox. Pas glop ! Si j’ai le courage, je finirai de faire mes tests et j’en ferai une synthèse.

CSP, une affaire à suivre donc.

Conclusion

Pour les utilisateurices de Kirby, ça vaudrait le coup d’aller creuser l’extension Kirby 3 Content Security Policy Header. Je pense que j’irai jeter un œil si ça peut m’aider à mettre en place une meilleure CSP.

Ce qu’il faut en retenir :

  1. Prenez le temps de vérifier si la redirection http/https est fonctionnelle sur votre site et mettez ensuite en place HSTS. Le rapport temps passé/gain de sécurité paraît intéressant.
  2. Ajouter les entêtes X-bidules ne mangent pas de pain, surtout si on n’est pas en mesure de mettre en place une CSP.
  3. Respecter une bonne hygiène sur son site en n’embarquant pas n’importe quel script, c’est limiter les risques (mais, ça on le savait déjà !) et s’éviter un énorme travail supplémentaire pour sécuriser le tout.
  4. Utilisez et soutenez Firefox .
  5. CSP pour un blog personnel ou un petit site demande encore un investissement en temps qui me semble considérable pour des personnes qui n’ont pas connaissance ou d’appétences techniques fortes. Je me doute que simplifier la mise en place et rendre ça presque aussi simple que les certificats SSL est un poil plus compliqué.

Je répète ici de ne pas copier sans réfléchir ce qui est évoqué ici et lire attentivement la documentation.

Je bidouille des sites web sur mon temps libre. La sécurité, la configuration de .htaccess, etc. ne relèvent absolument pas de mon domaine d’expertise.

Bidouillez, testez, amusez-vous en prenant les précautions nécessaires !

Ressources

  • « La sécurité de demain dans le web d'aujourd'hui : mission impossible ? », une conférence d’Aeris. Elle date un peu, mais présente bien le sujet et ce qu’il est possible ou non de mettre en place. Le constat semble lui toujours d’actualité. Je lui dois aussi la découverte de l’observatoire et l’antisèche sécurité de Mozilla.
  • HTTP headers : la documentation MDN est bien plus complète en anglais.
  • Mozilla Observatory : un outil pour vérifier la configuration de votre site et avoir des recommandations de corrections.
  • Web Security Cheat Sheet : un condensé de bonnes pratiques à mettre en place sur les sites web.

  1. Lire à ce sujet Clean up the web! et Misinformation about Permissions Policy and FLoC, qui est plus nuancé sur les impacts de FLoC. Pour résumer, ajouter cet entête n’a qu’un impact limité. Il vaut mieux vous inviter à ne plus utiliser Chrome/Chromium et les services Google. ↩︎

  2. Ce n’est pas complètement anodin, prenez bien connaissance des conséquences listées sur le site d’inscription. ↩︎

  3. J’imagine que la variable env=HTTPS n’est pas définie, ce qui explique pourquoi ça ne fonctionnait pas. Je dois ma solution à un forum de discussion cPanel. ↩︎

  4. SRI Hash Generator : si vous utilisez des contenus (scripts notamment) hébergés par des services tiers, essayez de creuser le sujet. Sinon, faites comme moi, hébergez tout chez vous ! ↩︎

Contact

Vous souhaitez réagir ? N’hésitez pas à m’écrire à contact@luce.carevic.eu.