Pourquoi les en-têtes HTTP de sécurité sont-ils importants ?

Les en-têtes de réponse HTTP (HTTP response headers) sont des métadonnées transmises par le serveur au navigateur avec chaque réponse. Les en-têtes de sécurité constituent une ligne de défense supplémentaire : ils instruisent le navigateur sur la manière de traiter le contenu de la page, limitant ainsi la surface d'attaque pour des vecteurs comme le Cross-Site Scripting (XSS), le clickjacking, l'injection de contenu ou la fuite de données via les redirections.

Mozilla Observatory, SecurityHeaders.com et Google Lighthouse évaluent la présence et la qualité de ces en-têtes dans leur score de sécurité. Des en-têtes correctement configurés peuvent faire passer votre score de sécurité de F à A+. Ils sont également pris en compte dans certains labels de sécurité et audits de conformité (PCI-DSS, ISO 27001).

HSTS — Strict-Transport-Security

HSTS (HTTP Strict Transport Security) est probablement l'en-tête de sécurité le plus impactant. Une fois reçu par le navigateur, il force toutes les requêtes futures vers ce domaine à utiliser HTTPS, même si l'utilisateur tape http:// dans la barre d'adresse. Le navigateur effectue lui-même la redirection, sans passer par le réseau.

La directive preload permet d'inscrire votre domaine dans la liste HSTS Preload intégrée dans les navigateurs (Chrome, Firefox, Safari, Edge). Les sites inscrits sont forcés en HTTPS dès la première visite, même sans avoir jamais reçu l'en-tête HSTS.

Valeur recommandée : max-age=31536000; includeSubDomains; preload

CSP — Content-Security-Policy

La Content Security Policy est l'en-tête de sécurité le plus puissant mais aussi le plus complexe à configurer. Elle définit une liste blanche de sources autorisées pour chaque type de ressource : scripts JavaScript (script-src), feuilles de style (style-src), images (img-src), polices (font-src), iframes (frame-src), etc.

Une CSP stricte bloque l'exécution de tout script inline non autorisé, ce qui neutralise la grande majorité des attaques XSS. La directive nonce ou hash permet d'autoriser spécifiquement certains scripts inline légitimes sans ouvrir la porte aux injections malveillantes.

En mode report-only, la CSP n'applique pas les restrictions mais envoie des rapports de violation à une URL définie, permettant de tester une politique sans risque de casser la fonctionnalité du site.

X-Frame-Options et la protection anti-clickjacking

Le clickjacking est une attaque qui consiste à superposer une iframe transparente d'un site légitime sur une page malveillante. L'utilisateur croit interagir avec la page malveillante alors qu'il clique en réalité sur des éléments du site légitime (boutons de validation, liens importants).

X-Frame-Options: DENY interdit toute intégration dans une iframe. SAMEORIGIN l'autorise uniquement si la page parente est sur le même domaine. La directive CSP frame-ancestors est le remplacement moderne de X-Frame-Options, offrant plus de granularité.

Comment ajouter ces en-têtes sur Apache / cPanel ?

Sur un hébergement Apache (comme tous nos hébergements cPanel), vous pouvez ajouter ces en-têtes via votre fichier .htaccess :

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>

Assurez-vous que le module mod_headers est activé sur votre serveur. Sur nos hébergements Gaprod, il l'est par défaut.

Comment ajouter ces en-têtes sur Nginx ?

Pour Nginx, les en-têtes se définissent dans le bloc server ou location de votre configuration :

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

En-têtes de sécurité et frameworks JavaScript

Les frameworks modernes comme Next.js, Nuxt, SvelteKit ou Remix permettent de définir les en-têtes de sécurité directement dans leur configuration. Next.js propose un fichier next.config.js avec un tableau headers. Cette approche est préférable car elle centralise la configuration et permet de définir des en-têtes différents selon les routes.

Pour les sites statiques (comme un export Next.js sur notre hébergement cPanel), le .htaccess reste la méthode appropriée pour définir ces en-têtes au niveau du serveur web Apache.

Headers HTTP de sécurité