La sécurité de votre site web est une priorité essentielle. Découvrez comment renforcer la protection de votre site grâce à différentes entêtes de sécurité.
HTTP Strict Transport Security (HSTS)
Le HSTS est une fonctionnalité essentielle pour soutenir votre site et renforcer l’implémentation de TLS. Recommandé avec la valeur « Strict-Transport-Security: max-age=31536000; includeSubDomains », le HSTS impose l’utilisation de HTTPS, limitant les risques d’attaques de type Man-in-the-Middle (MiTM). Apprenez comment intégrer cette fonctionnalité pour une communication plus sécurisée.
Activer le HSTS dans Apache:
Ajoutez le code suivant à votre fichier hosts virtuel:
Header always set Strict-Transport-Security max-age=31536000
Activer le HSTS dans NGINX
Ajoutez le code suivant à votre configuration NGINX.
add_header Strict-Transport-Security "max-age=31536000";
Utiliser le fichier .htaccess :
Vous pouvez également activer HSTS grâce au fichier .htaccess en ajoutant ce code à la fin du fichier :
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</IfModule>
Content Security Policy (CSP)
La CSP est une mesure efficace contre les attaques XSS. En définissant les sources de contenu approuvées, vous pouvez empêcher le chargement d’éléments malveillants. Livrée via un en-tête HTTP de réponse, la CSP offre une protection robuste contre les menaces. Explorez son déploiement facile et son efficacité dans la prévention des attaques XSS.
Compte tenu de la diversité des besoins des sites, il n’existe pas d’exemple universel. Explorons plutôt une variété de directives CSP, chacune adaptée pour permettre différents types de ressources.
Exemple 1: Utilisation d’un CDN avec des Restrictions
Cette directive autorise exclusivement les ressources d’un CDN tout en interdisant le contenu encadré et les plugins multimédias.
<IfModule mod_headers.c>
Header set Content-Security-Policy "default-src https://cdn.example.com; child-src 'none'; object-src 'none'"
</IfModule>
Exemple 2: Chargement de Scripts depuis un Sous-Domaine jQuery
Ici, les ressources script d’un sous-domaine jQuery sont autorisées, tandis que les feuilles de style et les images sont confinées au domaine actuel.
<IfModule mod_headers.c>
Header set Content-Security-Policy "default-src 'none'; img-src 'self'; script-src 'self' https://code.jquery.com; style-src 'self'"
</IfModule>
Exemple 3: Directive CSP Universelle pour WordPress
Pour les sites propulsés par WordPress, cette directive couvre les types de ressources courants, restant concise et efficace.
<IfModule mod_headers.c>
Header set Content-Security-Policy "default-src https:; font-src https: data:; img-src https: data:; script-src https:; style-src https:;"
</IfModule>
Ces exemples illustrent l’adaptabilité de CSP pour répondre à des besoins spécifiques. Lors de la mise en place de CSP, ajustez les directives pour correspondre aux exigences de votre site, assurant un environnement numérique sécurisé sans accrocs dans le chargement des ressources.
X-Frame-Options
Le X-Frame-Options définit si votre site peut être intégré dans un cadre (frame) ou non, protégeant ainsi contre les attaques de type clickjacking. La valeur recommandée est « X-Frame-Options: SAMEORIGIN ». Plongez dans les détails de cet en-tête essentiel pour sécuriser votre site contre les tentatives de manipulation des utilisateurs.
Ajouter dans le fichier de configuration du serveur web:
Vous pouvez ajouter cette option directement dans la configuration du serveur web. Pour ce faire, il suffit de modifier le fichier /etc/apache2/conf-available/security.conf pour ajouter la ligne suivante :
Header set X-Frame-Options: "sameorigin"
Ajouter via le fichier .htaccess:
Vous pouvez également activer cette option grâce au fichier .htaccess en ajoutant ce code à la fin du fichier :
<IfModule mod_headers.c>
Header set X-Frame-Options "SAMEORIGIN"
</IfModule>
X-Content-Type-Options
L’en-tête X-Content-Type-Options empêche le navigateur de deviner le type de contenu en se basant sur le MIME et le force à respecter le type de contenu déclaré. La valeur valide est « X-Content-Type-Options: nosniff ». Découvrez comment cette mesure réduit les risques de téléchargements malveillants et de contenus mal identifiés.
Ajouter dans le fichier de configuration du serveur web:
Vous pouvez ajouter cette option directement dans la configuration du serveur web. Pour ce faire, il suffit de modifier le fichier /etc/apache2/conf-available/security.conf pour ajouter la ligne suivante :
Header set X-Content-Type-Options: "nosniff"
Ajouter via le fichier .htaccess:
Vous pouvez également activer cette option grâce au fichier .htaccess en ajoutant ce code à la fin du fichier :
<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
</IfModule>
Referrer Policy
La Referrer Policy permet de contrôler les informations incluses avec les navigations hors d’un document. Proposée par le W3C, cette politique est définie via l’en-tête HTTP « Referrer-Policy ». Explorez les différentes valeurs, telles que « no-referrer » ou « strict-origin-when-cross-origin », pour adapter la politique à vos besoins de sécurité.
Les diverses directives à considérer sont les suivantes :
- no-referrer : Aucune en-tête referrer n’est transmise.
- no-referrer-when-downgrade : L’en-tête referrer est transmise si la sécurité de la destination est équivalente (de HTTPS vers HTTPS), mais aucune en-tête referrer n’est envoyée si la destination est moins sécurisée (HTTP).
- same-origin : L’en-tête referrer est transmise si l’URL a la même origine, mais aucune en-tête referrer n’est envoyée si la destination n’a pas la même origine.
- origin : L’en-tête referrer est transmise mais ne contient que l’origine (le domaine) et non l’URL complète.
- strict-origin : L’en-tête referrer contient uniquement l’origine (et non l’URL complète) si la destination est également sécurisée (HTTPS vers HTTPS). Si la destination n’est pas sécurisée (HTTP), aucune en-tête referrer n’est envoyée.
- origin-when-cross-origin : L’en-tête referrer contient l’URL complète si la destination a la même origine, et uniquement l’origine pour les autres cas.
- strict-origin-when-cross-origin : L’en-tête referrer contient l’URL complète si la destination a la même origine, et uniquement l’origine si la destination est également sécurisée (HTTPS vers HTTPS). Si la destination n’est pas sécurisée (HTTP), aucune en-tête referrer n’est envoyée.
- unsafe-url : L’en-tête referrer contient l’URL complète dans tous les cas (non recommandé).
Quant à ma politique, j’ai choisi de définir « strict-origin-when-cross-origin » comme directive à suivre.
Ajouter dans le fichier de configuration du serveur web:
Vous pouvez ajouter cette option directement dans la configuration du serveur web. Pour ce faire, il suffit de modifier le fichier /etc/apache2/conf-available/security.conf pour ajouter la ligne suivante :
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Ajouter via le fichier .htaccess:
Vous pouvez également activer cette option grâce au fichier .htaccess en ajoutant ce code à la fin du fichier :
<IfModule headers_module.c>
Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>
Définir l’en-tête Referrer-Policy via la configuration du vhost:
Vous pouvez définir la Referrer-Policy via la configuration du vhost aussi, il suffit d’ajouter les lignes suivantes, juste avant la balise </VirtualHost>:
<IfModule headers_module>
Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>
Permissions Policy
La Permissions Policy, nouvelle génération de Feature Policy, permet de contrôler les fonctionnalités et API autorisées dans le navigateur. Découvrez comment cette politique, définie par l’en-tête « Permissions-Policy », offre un contrôle granulaire sur les capacités du navigateur, renforçant ainsi la sécurité de votre site.
Protégez votre site web grâce à ces entêtes de sécurité recommandées. Suivez notre guide pour une mise en place efficace et une navigation sécurisée pour vos utilisateurs.
L’en-tête Permissions-Policy, désormais connu sous ce nom après avoir été renommé depuis Feature-Policy, offre les mêmes fonctionnalités. Voici la liste complète de ces fonctionnalités, qui vous sera particulièrement utile si vous envisagez de mettre en place l’en-tête Permissions-Policy à partir de zéro :
- accelerometer
- ambient-light-sensor
- autoplay
- battery
- camera
- display-capture
- document-domain
- encrypted-media
- fullscreen
- geolocation
- gyroscope
- layout-animations
- legacy-image-formats
- magnetometer
- microphone
- midi
- notifications
- oversized-images
- payment
- picture-in-picture
- publickey-credentials-get
- push
- speaker
- sync-xhr
- usb
- vibrate
- vr (encore actif, mais déprécié)
- wake-lock
- xr-spatial-tracking
Pour chacune de ces fonctionnalités, vous pouvez définir des directives spécifiques pour contrôler leur comportement. Les directives disponibles sont les suivantes :
*
: pour permettre la fonctionnalité, quelle que soit son origine.'self'
: pour autoriser les fonctionnalités uniquement si elles proviennent du même domaine.src
: permet de définir une source pour laquelle la fonctionnalité est activée.()
: pour interdire purement et simplement l’utilisation de la fonctionnalité.
Ajouter dans le fichier de configuration du serveur web:
Vous pouvez ajouter cette option directement dans la configuration du serveur web. Pour ce faire, il suffit de modifier le fichier /etc/apache2/conf-available/security.conf pour ajouter la ligne suivante :
Header set Permissions-Policy "accelerometer=(), geolocation=('self'), fullscreen=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), display-capture=('self')"
Ajouter via le fichier .htaccess:
Vous pouvez également activer cette option grâce au fichier .htaccess en ajoutant ce code à la fin du fichier :
<IfModule headers_module.c>
Header set Permissions-Policy "accelerometer=(), geolocation=('self'), fullscreen=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), display-capture=('self')"
</IfModule>
Définir l’en-tête Referrer-Policy via la configuration du vhost:
Vous pouvez définir cette politique via la configuration du vhost aussi, il suffit d’ajouter les lignes suivantes, juste avant la balise </VirtualHost>:
<IfModule headers_module>
Header set Permissions-Policy "accelerometer=(), geolocation=('self'), fullscreen=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), display-capture=('self')"
</IfModule>
n.b. N’oubliez pas d’adapter les paramètres à votre besoin, et toujours de vérifier les fonctionnalités votre site web après la mise en place de ces headers.
No responses yet