Durcir les en-têtes HTTP de sécurité

Ce guide s'adresse à quelqu'un qui administre déjà un serveur web Apache et veut ajouter (ou renforcer) les en-têtes HTTP de sécurité. On part du principe que vous savez éditer une config Apache, activer un module et recharger le service. Objectif : une configuration centralisée, testable, et une trajectoire vers une CSP stricte.

1. Centraliser plutôt que dupliquer

Configurez les en-têtes une seule fois, globalement, au lieu de les répéter dans chaque VirtualHost. Cela évite les oublis et garantit une politique homogène.

Activez le module headers :

sudo a2enmod headers

Créez un fichier de configuration dédié dans conf-available (par convention /etc/apache2/conf-available/security-headers.conf) :

<IfModule mod_headers.c>
    # Anti-clickjacking : interdit l'affichage du site en iframe
    Header always set X-Frame-Options "DENY"

    # Empêche le MIME sniffing
    Header always set X-Content-Type-Options "nosniff"

    # Limite les infos de provenance transmises
    Header always set Referrer-Policy "strict-origin-when-cross-origin"

    # Désactive les fonctions navigateur non utilisées
    Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"

    # Isolation cross-origin (renforce l'isolement du contexte navigateur)
    Header always set Cross-Origin-Embedder-Policy "require-corp"
    Header always set Cross-Origin-Opener-Policy "same-origin"
    Header always set Cross-Origin-Resource-Policy "same-origin"

    # Content-Security-Policy : voir section dédiée. Laissée commentée
    # tant que des scripts inline hérités subsistent.
    # Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; connect-src 'self'; frame-ancestors 'none';"
</IfModule>

Le mot-clé always garantit que l'en-tête est posé même sur les réponses d'erreur (4xx/5xx).

Activez la config, vérifiez la syntaxe, rechargez :

sudo a2enconf security-headers
sudo apache2ctl -t
sudo systemctl reload apache2

2. Content-Security-Policy : la trajectoire

La CSP est l'en-tête le plus efficace contre le XSS et l'injection, mais aussi le plus susceptible de casser une page. Ne l'activez pas en aveugle sur un site existant.

Pour atteindre une politique stricte (sans 'unsafe-inline') :

1. Externalisez tous les scripts inline dans des fichiers .js servis par votre origine.
2. Remplacez les styles inline, ou autorisez-les par hash/nonce plutôt que par 'unsafe-inline'.
3. Retirez 'unsafe-inline' de script-src.
4. Décommentez et activez le header CSP.

3. CSP en mode Report-Only (pré-production)

Pour cartographier les besoins réels avant de bloquer quoi que ce soit, déployez d'abord une CSP en observation. Elle ne bloque rien : elle signale les violations.

# Endpoint de collecte des rapports — adaptez l'URL à votre domaine
Header always set Reporting-Endpoints "csp-endpoint=\"https://<VOTRE_DOMAINE>/reports\""

# Politique en observation uniquement (aucun blocage)
Header always set Content-Security-Policy-Report-Only "default-src 'self'; object-src 'none'; frame-ancestors 'none'; report-to csp-endpoint"

Procédure :

• Déployez ces en-têtes en pré-production.
• Naviguez sur les pages clés, ouvrez la console navigateur et collectez les rapports remontés.
• Recensez les ressources externes légitimes ; remplacez l'inline par des fichiers, ou autorisez-le via hash/nonce.
• Une fois la liste stabilisée, retirez Report-Only et passez à une Content-Security-Policy stricte.

Références : documentation MDN sur la CSP et la Reporting API.

4. HSTS

Le Strict-Transport-Security (HSTS) force le navigateur à n'utiliser que HTTPS. Il se gère à part car il suppose que le TLS est déjà en place et fiable sur tout le domaine (sous peine de rendre un site inaccessible). Traitez-le dans la procédure dédiée Mettre en place SSL/TLS une fois HTTPS pleinement opérationnel.

5. Vérifier le résultat

Inspectez les en-têtes réellement servis :

curl -sI https://<VOTRE_DOMAINE> | egrep -i "^(strict-transport-security|x-frame-options|x-content-type-options|referrer-policy|permissions-policy|cross-origin-.*|content-security-policy|content-security-policy-report-only|server|x-powered-by):"

Attendus :

• Présence : HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, COEP/COOP/CORP.
• CSP active ou en report-only selon l'environnement.
• Sobriété : en-tête Server non verbeux ; pas de X-Powered-By (ces en-têtes révèlent versions et stack, à masquer).

Outils en ligne pour un audit complémentaire :

• securityheaders.com
• Mozilla Observatory

À retenir

• Une config globale unique vaut mieux que des réglages par vhost.
• La CSP se déploie en deux temps : observation (Report-Only), puis blocage strict.
• HSTS uniquement quand HTTPS est solide sur tout le domaine.
• Réduisez la verbosité (Server, X-Powered-By) : ne divulguez pas votre stack.