Les headers HTTP de sécurité sont souvent négligés, mais ils constituent une défense simple et efficace contre de nombreuses attaques courantes. Configurer correctement 6 headers suffit à éliminer des classes entières de vulnérabilités.

Pourquoi les headers de sécurité sont critiques

Un header mal configuré (ou absent) peut permettre :

Le clickjacking (X-Frame-Options manquant)
L'injection de scripts malveillants via XSS (CSP absent)
L'interception des communications en clair (HSTS absent)
La fuite d'informations sur votre stack technique (Server header exposé)

WarDek analyse automatiquement ces 12 headers lors de chaque scan.

Les 6 headers essentiels

1. Strict-Transport-Security (HSTS)

Force les navigateurs à utiliser HTTPS pour toutes les connexions futures, même si l'utilisateur tape http://.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Paramètres :

max-age=31536000 : 1 an (minimum recommandé)
includeSubDomains : applique la règle aux sous-domaines
preload : inscription à la liste HSTS preload des navigateurs

Attention : Une fois activé avec preload, difficile à annuler. Testez d'abord avec un max-age court.

2. Content-Security-Policy (CSP)

Le header le plus puissant — et le plus complexe. Définit les sources autorisées pour chaque type de ressource.

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; frame-ancestors 'none'

Règles de base :

Commencer par default-src 'self' pour bloquer tout par défaut
Éviter 'unsafe-inline' et 'unsafe-eval' autant que possible
Utiliser des nonces pour les scripts inline légitimes
Activer Content-Security-Policy-Report-Only d'abord pour tester sans bloquer

3. X-Frame-Options

Protège contre le clickjacking en contrôlant qui peut embarquer votre page dans un iframe.

X-Frame-Options: DENY

Ou pour autoriser uniquement votre propre domaine :

X-Frame-Options: SAMEORIGIN

Note : frame-ancestors dans CSP est plus flexible et remplace X-Frame-Options dans les navigateurs modernes. Gardez les deux pour la compatibilité.

4. X-Content-Type-Options

Empêche le navigateur de deviner le type MIME d'une ressource (MIME sniffing), ce qui peut mener à l'exécution de code malveillant.

X-Content-Type-Options: nosniff

Simple, une seule valeur possible. Activez-le systématiquement.

5. Referrer-Policy

Contrôle les informations envoyées dans le header Referer lors des navigations entre pages.

Referrer-Policy: strict-origin-when-cross-origin

Cela limite la fuite d'URLs internes (qui pourraient contenir des tokens ou des données sensibles) lors des requêtes cross-origin.

6. Permissions-Policy (ex Feature-Policy)

Contrôle l'accès aux APIs du navigateur (caméra, micro, géolocalisation, etc.).

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()

Si votre application n'utilise pas ces APIs, désactivez-les pour réduire la surface d'attaque.

Headers à supprimer

Tout aussi important : supprimer les headers qui révèlent des informations sur votre infrastructure.

Server: Apache/2.4.51 → supprimer ou remplacer par Server:
X-Powered-By: PHP/8.1.0 → supprimer avec expose_php = Off
X-AspNet-Version → supprimer dans web.config

Ces headers facilitent la reconnaissance automatisée. Un attaquant qui identifie votre version d'Apache ou de PHP peut immédiatement chercher les CVE correspondantes dans les bases de vulnérabilités publiques.

Implémentation selon votre stack

Nginx

server {
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    add_header Content-Security-Policy "default-src 'self'; script-src 'self'" always;
    add_header X-Frame-Options "DENY" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

    # Supprimer les headers informatifs
    server_tokens off;
    proxy_hide_header X-Powered-By;
}

Apache

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

# Masquer la version
ServerTokens Prod
ServerSignature Off

Next.js / Vercel

// next.config.ts
const securityHeaders = [
  { key: 'Strict-Transport-Security', value: 'max-age=31536000; includeSubDomains; preload' },
  { key: 'X-Frame-Options', value: 'DENY' },
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
];

Erreurs fréquentes

CSP trop permissive. Un Content-Security-Policy: default-src * ne protège contre rien. Commencez restrictif ('self') et ajoutez des exceptions une par une.

HSTS sans test préalable. Activer preload sur un domaine qui n'est pas entièrement en HTTPS peut rendre votre site inaccessible. Testez d'abord avec un max-age court (300 secondes).

Oublier les sous-domaines. Sans includeSubDomains dans HSTS, un attaquant peut exploiter un sous-domaine non sécurisé pour intercepter les cookies du domaine principal.

Dupliquer CSP et X-Frame-Options de manière contradictoire. Si votre CSP dit frame-ancestors 'self' mais votre X-Frame-Options dit DENY, le comportement dépend du navigateur. Alignez les deux.

Comment vérifier votre configuration

WarDek : Scan automatique de tous vos headers avec score et recommandations
securityheaders.com : Outil gratuit pour une vérification rapide
curl : curl -I https://votresite.com pour voir les headers bruts
DevTools navigateur : Onglet Network → sélectionnez la requête principale → Headers de réponse

Un bon score sur les headers de sécurité améliore aussi votre score SEO (Google favorise les sites HTTPS bien configurés) et votre conformité NIS2. La directive NIS2 (Article 21) exige explicitement des mesures de sécurité réseau, dont les headers HTTP font partie intégrante.

Headers HTTP de sécurité : le guide complet pour 2025