Le guide complet de la sécurité web : CORS, CSP et HSTS

1. CORS (Cross-Origin Resource Sharing) : sécuriser vos API

Pour comprendre CORS, il faut d’abord comprendre la Same-Origin Policy (SOP). Par défaut, les navigateurs web empêchent les pages web d’envoyer des requêtes vers un domaine (origine) différent de celui qui a servi la page. Par exemple, un script sur https://myblog.com ne peut pas récupérer arbitrairement des données privées depuis https://api.mybank.com. C’est un mécanisme de défense intégré essentiel.

Cependant, les applications mondiales modernes sont fortement décentralisées. Votre frontend peut être hébergé sur Vercel, votre API sur AWS, et vos images sur Cloudflare. CORS est le protocole qui vous permet de contourner en toute sécurité la SOP. Il utilise des en-têtes HTTP spécialisés pour indiquer au navigateur : « Il est acceptable que ce domaine externe spécifique accède à mes ressources. »

• La requête preflight : pour les requêtes complexes (comme l’envoi de données JSON via POST ou PUT), le navigateur envoie d’abord une requête OPTIONS invisible (le « preflight ») pour demander au serveur si la requête réelle est autorisée. Si le serveur approuve, la vraie requête est envoyée.
• L’erreur fatale : de nombreux développeurs, frustrés par les erreurs CORS, se contentent de définir Access-Control-Allow-Origin: * (le joker). C’est une vulnérabilité de sécurité catastrophique, car cela permet littéralement à n’importe quel site web sur Internet d’interroger votre API. Spécifiez toujours des origines exactes et de confiance.

2. CSP (Content Security Policy) : le bouclier ultime contre le XSS

Le Cross-Site Scripting (XSS) est l’une des vulnérabilités les plus courantes et les plus dangereuses du web. Elle se produit lorsqu’un pirate parvient à injecter du JavaScript malveillant sur votre site (par exemple, via une section de commentaires vulnérable). Lorsqu’un utilisateur visite la page, le script malveillant s’exécute, volant ses cookies de session ou le redirigeant vers un site de phishing.

CSP agit comme un videur incroyablement strict pour votre page web. C’est un en-tête HTTP qui permet aux administrateurs de site de déclarer une « liste blanche » approuvée de ressources dynamiques autorisées à se charger. Si un script tente de s’exécuter mais que son origine ne figure pas sur la liste blanche, le navigateur le bloque simplement.

3. HSTS (HTTP Strict Transport Security) : imposer la voie sécurisée

Vous avez installé un certificat SSL/TLS, et votre site se charge en HTTPS. Vous êtes en sécurité, n’est-ce pas ? Pas tout à fait. Lorsqu’un utilisateur saisit manuellement yourdomain.com dans son navigateur, la requête initiale utilise souvent par défaut le protocole non chiffré http://. Dans cette fraction de seconde avant que votre serveur ne le redirige vers https://, un pirate connecté au même réseau Wi-Fi public peut exécuter une attaque de déchiffrement SSL de type Man-In-The-Middle (MITM), interceptant le trafic.

HSTS élimine complètement cette fenêtre de vulnérabilité. Lorsqu’un serveur envoie l’en-tête HSTS, il donne un ordre strict au navigateur : « Pendant les X prochaines unités de temps, n’essaie jamais de charger ce site via HTTP. Force le HTTPS en interne avant même que la requête ne quitte l’appareil. » De plus, vous pouvez soumettre votre domaine à la liste de préchargement HSTS mondiale, codée en dur dans Chrome, Firefox et Safari, garantissant que les utilisateurs se connectent de manière sécurisée dès leur toute première visite.

4. Mise en pratique : extraits de configuration serveur

Mettre en œuvre ces politiques nécessite de modifier la configuration de votre serveur. Voici un extrait prêt pour la production pour Nginx qui configure un CORS strict, un CSP robuste, et un HSTS à sécurité maximale.

server {
    listen 443 ssl http2;
    server_name www.yourglobaldomain.com;

    # 1. Configuration HSTS
    # Impose HTTPS pendant 1 an (31536000 secondes), inclut les sous-domaines, et autorise le preload
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    # 2. Configuration CSP (Content Security Policy)
    # N'autorise les scripts que depuis votre domaine et Google Analytics. Interdit les scripts inline.
    add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://www.google-analytics.com; img-src 'self' data: https:; style-src 'self' 'unsafe-inline';" always;

    # 3. Configuration CORS (pour un bloc API)
    location /api/ {
        # N'utilisez JAMAIS '*' en production. Spécifiez les domaines frontend exacts de confiance.
        add_header 'Access-Control-Allow-Origin' 'https://www.yourfrontend.com' always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE' always;
        add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type' always;
        
        # Gérer les requêtes preflight
        if ($request_method = 'OPTIONS') {
            add_header 'Access-Control-Allow-Origin' 'https://www.yourfrontend.com';
            add_header 'Access-Control-Max-Age' 1728000;
            add_header 'Content-Type' 'text/plain; charset=utf-8';
            add_header 'Content-Length' 0;
            return 204;
        }
    }
}

Conclusion : la sécurité, c’est du SEO

Dans l’écosystème web moderne, sécurité et SEO sont profondément liés. Google utilise explicitement le HTTPS comme signal de classement, et ses algorithmes sont extrêmement sensibles aux indicateurs de sécurité des utilisateurs. En mettant correctement en œuvre CORS, CSP et HSTS, vous ne protégez pas seulement les données de vos utilisateurs — vous construisez un actif numérique résilient et digne de confiance, que les moteurs de recherche recommanderont avec assurance à des audiences mondiales. Auditez dès aujourd’hui vos en-têtes HTTP et fermez la porte aux acteurs malveillants.

Tags : #SécuritéWeb #CORS #ContentSecurityPolicy #HSTS #Cybersécurité #SEOMondial #HTTPS #StandardsTech