Ainsi, nos utilisateurs ne sont pas à l’abri tant que les navigateurs leur permettent d’être la cible d’attaques, telles que le vol de session via un lien dissimulant une injection de script JavaScript.
Pour sensibiliser aux risques de ces attaques potentielles, Mozilla a mis au point un outil permettant d’analyser les failles de sécurité éventuelles d’un site tout en fournissant des conseils de correction. En tant que développeurs d’applications, il nous incombe de protéger nos utilisateurs en installant les bons mécanismes de verrouillage pour refermer cette porte.
Mozilla Observatory#
Dans cette série d’articles, nous allons voir les principales erreurs que peut remonter l’outil Mozilla Observatory, les comprendre et voir comment les corriger.
Lorsqu’on arrive sur le site https://observatory.mozilla.org/, on nous invite à rentrer l’URL du site que l’on souhaite analyser. Essayons donc avec akawaka.fr.
On obtient une note de D, sachant que la pire note est F. Ce qui est bien, mais pas top ! En regardant la fiche de résultat, on remarque trois sections :
- 1
La notation
En haut à gauche, des infos sur la notation du site : on remarque ici un score de 35/100 avec 6 tests passés sur 11. Sachez également que par défaut, votre analyse sera conservée dans les statistiques publiques de Mozilla. - 2
La recommandation prioritaire
En haut à droite, la règle la plus urgente à corriger. Ici Mozilla Observatory nous conseille d’ajouter l’en-têteX-Frame-Optionsavant toute chose. - 3
Le détail des règles
Enfin, la liste de toutes les règles évaluées par Mozilla Observatory sur notre site, avec pour chacune le résultat du test et son score.
HTTPS et redirection#
Aujourd’hui, le sujet de mettre HTTPS ou non sur un site est devenu un non-sujet avec l’arrivée de Let’s Encrypt et surtout de la gratuité des certificats. Encore faut-il correctement configurer la redirection pour ne pas laisser les visiteurs accéder au site sous HTTP.
Pour chaque règle, Mozilla nous fournit un lien vers leur documentation avec une explication de la règle évaluée, ainsi que des éléments de réponse pour corriger.
La redirection HTTP vers HTTPS#
Dans le cas de la règle Redirection, la documentation nous dit qu’un site doit être disponible via le protocole HTTPS et que tout accès au site via le protocole non sécurisé HTTP doit être redirigé vers sa version sécurisée. Pour ce faire, c’est au niveau de la configuration du serveur HTTP que cela se passe et Mozilla nous fournit un exemple pour les deux principales solutions, Nginx et Apache.
# Redirect all incoming http requests to the same site and URI on https, using nginx
server {
listen 80;
return 301 https://$host$request_uri;
}# Redirect for site.example.org from http to https, using Apache
<VirtualHost *:80>
ServerName site.example.org
Redirect permanent / https://site.example.org/
</VirtualHost>Si cette règle est plutôt bien connue de la majorité, la suivante l’est un peu moins.
HTTP Strict Transport Security (HSTS)#
HTTP Strict Transport Security : cet en-tête HTTP permet de dire au navigateur que la prochaine fois qu’il se connectera au site avec le protocole HTTP, pas besoin d’initier la requête, il doit passer directement sur le protocole HTTPS.
Sachez également que cet en-tête force le navigateur à être plus strict sur les erreurs TLS et interdit à l’utilisateur d’ignorer ces erreurs. Par exemple via une page sensibilisant l’utilisateur qu’il prend un risque s’il continue sur ce site alors que le certificat semble erroné.
Cet en-tête possède 3 paramètres :
max-age: définit le temps en secondes durant lequel le navigateur effectue la redirection automatiquement.includeSubDomains(optionnel) : définit que la règle s’applique également aux sous-domaines du domaine courant. Par exemple pour domain.example.com, la redirection en HTTPS sera également faite sur host1.domain.example.com, host2.domain.example.com, etc.preload(optionnel) : ce paramètre permet d’inscrire notre site dans la “Preload HSTS list”. C’est une liste, initialement faite pour Chrome, regroupant tous les sites définissant l’en-tête HSTS et donc certifiant que son site est bien disponible en HTTPS. Aujourd’hui la majorité des navigateurs regardent dans cette liste pour savoir si un site est bien accessible en HTTPS. Vous pouvez ajouter le vôtre manuellement via le site https://hstspreload.org/, ou ajouter l’optionpreload.
Enfin, Mozilla nous donne quelques exemples pour illustrer cet en-tête.
# Only connect to this site via HTTPS for the two years (recommended)
Strict-Transport-Security: max-age=63072000
# Only connect to this site and subdomains via HTTPS for the next two years and also include in the preload list
Strict-Transport-Security: max-age=63072000; includeSubDomains; preloadMozilla Observatory — À suivre#
Nous verrons la suite des règles dans nos prochains articles, les attaques concernées et comment s’en prémunir.
Chez AKAWAKA, nous sommes fermement convaincus de la valeur de l’outil Mozilla Observatory. C’est pourquoi il est désormais intégré à nos nombreux points de contrôle en plus de la qualité et des bonnes pratiques du code de votre application, l’outillage de votre environnement de développement, les processus d’intégration et de déploiement continu, et bien d’autres aspects.
N’hésitez pas à nous contacter si votre site obtient une note défavorable. Nous serons ravis de vous accompagner, que ce soit pour la mise en œuvre ou pour des conseils, afin d’améliorer la sécurité de votre plateforme.
👉 La suite : Partie 2 – X-Frame-Options et CORS.