Qu’est-ce qu’un Header HTTP/HTTPS ?
Un header HTTP ou HTTPS est un champ d’en-tête ajouté à une requête ou une réponse HTTP pour fournir des informations supplémentaires sur le transfert de données. Ces informations peuvent inclure la gestion des cookies, la politique de sécurité, le type de contenu, ou encore les directives de cache.
Headers Courants dans les Requêtes HTTP/HTTPS :
- Host : Indique le nom de domaine du serveur auquel la requête est adressée.
- User-Agent : Identifie le client (navigateur) qui fait la requête.
- Accept : Spécifie les types de contenu que le client peut traiter (par exemple, HTML, JSON).
- Authorization : Utilisé pour transmettre les informations d’identification (authentification de base).
- Referer : Indique l’URL de la page d’où provient la requête.
- Connection : Gère la persistance de la connexion (ex.
keep-alive
ouclose
).
Headers Utilisés dans les Réponses HTTP/HTTPS :
- Content-Type : Indique le type de contenu renvoyé par le serveur (par exemple,
text/html
ouapplication/json
). - Set-Cookie : Gère la transmission de cookies du serveur au client.
- Cache-Control : Définit les directives de cache pour le contenu.
- Strict-Transport-Security (HSTS) : Indique que le serveur doit être accessible uniquement via HTTPS pour une durée définie.
- Content-Security-Policy (CSP) : Précise les sources de contenu sûres pour prévenir des attaques comme le XSS (Cross-Site Scripting).
II. Configuration Sécurisée d’Apache : Étapes Essentielles
La sécurité d’un serveur Apache repose sur la bonne configuration des headers HTTP/HTTPS et d’autres paramètres. Voici une configuration Apache sécurisée, expliquée étape par étape :
1. Forcer l’Utilisation du HTTPS
C’est l’une des premières règles pour sécuriser un serveur. Vous devez forcer toutes les connexions HTTP à être redirigées vers HTTPS afin de garantir que les données sont transmises de manière cryptée.
<VirtualHost *:80>
ServerName exemple.com
Redirect permanent / https://exemple.com/
</VirtualHost>
Pourquoi ?
Le HTTPS utilise SSL/TLS pour sécuriser les données échangées entre le client et le serveur. Cela protège contre les attaques de type « Man-in-the-middle » (MITM) où un attaquant pourrait intercepter et manipuler les données.
2. Activer HSTS (Strict-Transport-Security)
Le header HSTS indique aux navigateurs qu’ils doivent exclusivement utiliser HTTPS pour communiquer avec votre site.
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
Pourquoi ?
Cela empêche les navigateurs d’accéder à votre site via une connexion non sécurisée pendant la période définie (dans cet exemple : 2 ans), même si l’utilisateur saisit l’URL en HTTP. Le paramètre includeSubDomains
renforce cette directive pour tous les sous-domaines.
3. Implémenter Content-Security-Policy (CSP)
La politique de sécurité de contenu permet de contrôler les sources de contenu que le navigateur peut charger, ce qui limite les risques d’attaques XSS.
Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://apis.google.com; object-src 'none'"
Pourquoi ?
CSP permet de restreindre les sources de scripts, d’images, de styles, etc. En spécifiant default-src 'self'
, vous autorisez uniquement les ressources provenant de votre propre domaine. Cela bloque l’inclusion de scripts potentiellement malveillants venant de sources tierces.
4. Désactiver les Headers Inutiles et Sensibles
Certaines informations ne devraient pas être divulguées dans les headers de réponse HTTP. Vous pouvez désactiver l’envoi de certains headers Apache pour éviter de donner des informations utiles à un attaquant.
ServerSignature Off
ServerTokens Prod
Header unset X-Powered-By
Pourquoi ?
ServerSignature Off
et ServerTokens Prod
empêchent la divulgation de la version d’Apache, réduisant ainsi le risque que les attaquants exploitent une version vulnérable. De plus, en supprimant le header X-Powered-By
, vous ne révélez pas la technologie ou la version de PHP utilisée.
5. Configurer X-Frame-Options
Le header X-Frame-Options
empêche votre site d’être inclus dans un iframe sur un autre site, protégeant contre les attaques de type « Clickjacking ».
Header always set X-Frame-Options "DENY"
Pourquoi ?
Cette directive refuse toute inclusion de votre site dans un iframe, ce qui est utile pour éviter les situations où un attaquant pourrait capturer des clics de l’utilisateur sur des pages de votre site (Clickjacking).
6. Limiter la Politique de Référencement avec Referrer-Policy
Vous pouvez contrôler quelles informations de l’URL source sont envoyées dans le header Referer
lors de la navigation sur des sites externes.
Header set Referrer-Policy "no-referrer-when-downgrade"
Pourquoi ?
Cette politique assure que votre site ne transmet pas d’informations sensibles en HTTP si le client passe d’une page HTTPS à HTTP. Elle protège également les données d’URL transmises à d’autres sites.
7. Limiter la Durée des Cookies et Ajouter le Flag Secure
Les cookies de session doivent être configurés pour être transmis uniquement via HTTPS, et leur durée de vie doit être limitée.
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure;SameSite=Strict
Pourquoi ?
Le flag HttpOnly
protège les cookies contre les attaques de scripts côté client (XSS), Secure
limite leur transmission aux connexions HTTPS, et SameSite=Strict
empêche leur envoi lors des requêtes intersites (CSRF).
8. Activer la Compression Gzip de Manière Sécurisée
Bien que la compression Gzip améliore les performances en réduisant la taille des réponses, elle doit être configurée de manière sécurisée pour éviter certaines vulnérabilités (ex. CRIME attack).
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css
AddOutputFilterByType DEFLATE application/javascript application/json
</IfModule>
Pourquoi ?
La compression permet d’améliorer les performances en réduisant la taille des fichiers transférés. Toutefois, il est important de limiter les types de fichiers compressés pour réduire les risques d’exploitation d’attaques liées à la compression.