Durcissement de la sécurité Frontend : Content Security Policy et CORS

Dans le paysage numérique interconnecté d'aujourd'hui, la sécurité frontend est primordiale. Les applications web sont de plus en plus ciblées par des attaques sophistiquées, rendant les mesures de sécurité robustes essentielles. Deux composants critiques d'une architecture frontend sécurisée sont la Content Security Policy (CSP) et le Cross-Origin Resource Sharing (CORS). Ce guide complet offre un aperçu approfondi de ces technologies, proposant des exemples pratiques et des insights actionnables pour vous aider à fortifier vos applications web contre les menaces modernes.

Qu'est-ce que la Content Security Policy (CSP) ?

La Content Security Policy (CSP) est une couche de sécurité supplémentaire qui aide à détecter et à atténuer certains types d'attaques, y compris les attaques par Cross-Site Scripting (XSS) et par injection de données. La CSP est implémentée par le serveur web qui envoie un en-tête de réponse HTTP Content-Security-Policy au navigateur. Cet en-tête définit une liste blanche des sources à partir desquelles le navigateur est autorisé à charger des ressources. En restreignant les sources de contenu qu'un navigateur peut charger, la CSP rend beaucoup plus difficile pour les attaquants d'injecter du code malveillant sur votre site web.

Comment fonctionne la CSP

La CSP fonctionne en indiquant au navigateur de ne charger que les ressources (par exemple, scripts, feuilles de style, images, polices) provenant de sources approuvées. Ces sources sont spécifiées dans l'en-tête CSP à l'aide de directives. Si un navigateur tente de charger une ressource depuis une source qui n'est pas explicitement autorisée, il bloquera la requête et signalera une violation.

Directives CSP : Un aperçu complet

Les directives CSP contrôlent les types de ressources qui peuvent être chargées à partir de sources spécifiques. Voici une ventilation de certaines des directives les plus importantes :

• default-src : Spécifie la source par défaut pour tous les types de contenu. Il s'agit d'une directive de repli qui s'applique lorsque d'autres directives, plus spécifiques, ne sont pas présentes.
• script-src : Spécifie les sources à partir desquelles les scripts peuvent être chargés. Ceci est crucial pour prévenir les attaques XSS.
• style-src : Spécifie les sources à partir desquelles les feuilles de style peuvent être chargées.
• img-src : Spécifie les sources à partir desquelles les images peuvent être chargées.
• font-src : Spécifie les sources à partir desquelles les polices peuvent être chargées.
• media-src : Spécifie les sources à partir desquelles l'audio et la vidéo peuvent être chargés.
• object-src : Spécifie les sources à partir desquelles les plugins (par exemple, Flash) peuvent être chargés. Ceci est souvent défini sur 'none' pour désactiver complètement les plugins en raison de leurs risques de sécurité inhérents.
• frame-src : Spécifie les sources à partir desquelles les cadres (par exemple, <iframe>) peuvent être chargés.
• connect-src : Spécifie les URL auxquelles l'agent utilisateur peut se connecter à l'aide d'interfaces de script telles que XMLHttpRequest, WebSocket et EventSource.
• base-uri : Spécifie les URL qui peuvent être utilisées dans l'élément <base> d'un document.
• form-action : Spécifie les URL vers lesquelles les soumissions de formulaires peuvent être envoyées.
• upgrade-insecure-requests : Indique à l'agent utilisateur de mettre à niveau automatiquement les requêtes non sécurisées (HTTP) vers des requêtes sécurisées (HTTPS).
• report-uri : Spécifie une URL où le navigateur doit envoyer des rapports sur les violations de CSP. Cette directive est dépréciée au profit de `report-to`.
• report-to : Spécifie un nom de groupe de rapports défini dans l'en-tête `Report-To`, où le navigateur doit envoyer des rapports sur les violations de CSP.

Mots-clés de liste de sources CSP

Dans les directives CSP, vous pouvez utiliser des mots-clés de liste de sources pour définir les sources autorisées. Voici quelques mots-clés courants :

• 'self' : Autorise les ressources de la même origine (schéma et hôte) que le document.
• 'none' : Refuse les ressources de toutes les sources.
• 'unsafe-inline' : Autorise l'utilisation de scripts et de styles en ligne (par exemple, les balises <script> et les attributs de style). À utiliser avec une extrême prudence car cela affaiblit considérablement la protection CSP contre le XSS.
• 'unsafe-eval' : Autorise l'utilisation de fonctions d'évaluation de code dynamique comme eval() et Function(). À utiliser avec une extrême prudence car cela introduit des risques de sécurité importants.
• 'unsafe-hashes' : Autorise les gestionnaires d'événements en ligne spécifiques ou les balises <style> qui correspondent à un hachage spécifié. Nécessite la prise en charge par le navigateur. À utiliser avec prudence.
• 'strict-dynamic' : Spécifie que la confiance explicitement accordée à un script présent dans le balisage, en l'accompagnant d'un nonce ou d'un hachage, sera propagée à tous les scripts chargés par ce script racine.
• data : Autorise les URI data: (par exemple, images en ligne codées en base64). À utiliser avec prudence.
• https:: Autorise le chargement de ressources via HTTPS depuis n'importe quel domaine.
• [hostname] : Autorise les ressources d'un domaine spécifique (par exemple, example.com). Vous pouvez également spécifier un numéro de port (par exemple, example.com:8080).
• [scheme]://[hostname]:[port] : Une URI entièrement qualifiée, autorisant les ressources du schéma, de l'hôte et du port spécifiés.

Exemples pratiques de CSP

Jetons un œil à quelques exemples pratiques d'en-têtes CSP :

Exemple 1 : CSP de base avec 'self'

Cette politique autorise les ressources uniquement depuis la même origine :

            Content-Security-Policy: default-src 'self'
            

              
                Copy
              
            
          

Exemple 2 : Autoriser les scripts d'un domaine spécifique

Cette politique autorise les scripts de votre propre domaine et d'un CDN de confiance :

            Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com
            

              
                Copy
              
            
          

Exemple 3 : Désactiver les scripts et styles en ligne

Cette politique refuse les scripts et styles en ligne, ce qui constitue une défense solide contre le XSS :

            Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'
            

              
                Copy
              
            
          

Important : La désactivation des scripts en ligne nécessite de refactoriser votre HTML pour déplacer les scripts en ligne vers des fichiers externes.

Exemple 4 : Utilisation de nonces pour les scripts en ligne

Si vous devez utiliser des scripts en ligne, utilisez des nonces (jetons cryptographiquement aléatoires à usage unique) pour autoriser des blocs de scripts en ligne spécifiques. C'est plus sûr que 'unsafe-inline'. Le serveur doit générer un nonce unique pour chaque requête et l'inclure à la fois dans l'en-tête CSP et dans la balise <script>.

            Content-Security-Policy: default-src 'self'; script-src 'nonce-r4nd0mN0nc3'; style-src 'self'
            

              
                Copy
              
            
          

            <script nonce="r4nd0mN0nc3"> console.log('Inline script'); </script>
            

              
                Copy
              
            
          

Note : N'oubliez pas de générer un nouveau nonce pour chaque requête. Ne réutilisez pas les nonces !

Exemple 5 : Utilisation de hachages pour les styles en ligne

Semblable aux nonces, les hachages peuvent être utilisés pour autoriser des blocs de <style> en ligne spécifiques. Ceci est fait en générant un hachage SHA256, SHA384 ou SHA512 du contenu du style.

            Content-Security-Policy: default-src 'self'; style-src 'sha256-HASHEDSTYLES'
            

              
                Copy
              
            
          

            <style sha256="HASHEDSTYLES"> body { background-color: #f0f0f0; } </style>
            

              
                Copy
              
            
          

Note : Les hachages sont moins flexibles que les nonces car toute modification du contenu du style invalidera le hachage.

Exemple 6 : Signalement des violations de CSP

Pour surveiller les violations de CSP, utilisez la directive report-uri ou report-to :

            Content-Security-Policy: default-src 'self'; report-to csp-endpoint;
            

              
                Copy
              
            
          

Vous devrez également configurer l'en-tête Report-To. L'en-tête Report-To définit un ou plusieurs groupes de rapports, qui spécifient où et comment les rapports doivent être envoyés.

            Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"https://example.com/csp-report"}]}
            

              
                Copy
              
            
          

Test et déploiement de la CSP

La mise en œuvre de la CSP nécessite une planification et des tests minutieux. Commencez par une politique restrictive et assouplissez-la progressivement si nécessaire. Utilisez l'en-tête Content-Security-Policy-Report-Only pour tester votre politique sans bloquer les ressources. Cet en-tête signale les violations sans appliquer la politique, vous permettant d'identifier et de corriger les problèmes avant de déployer la politique en production.

            Content-Security-Policy-Report-Only: default-src 'self'; report-to csp-endpoint;
            

              
                Copy
              
            
          

Analysez les rapports générés par le navigateur pour identifier toute violation et ajustez votre politique en conséquence. Une fois que vous êtes convaincu que votre politique fonctionne correctement, déployez-la à l'aide de l'en-tête Content-Security-Policy.

Bonnes pratiques pour la CSP

• Commencez par un default-src : Définissez toujours un default-src pour établir une politique de base.
• Soyez spécifique : Utilisez des directives et des mots-clés de liste de sources spécifiques pour limiter la portée de votre politique.
• Évitez 'unsafe-inline' et 'unsafe-eval' : Ces mots-clés affaiblissent considérablement la CSP et doivent être évités dans la mesure du possible.
• Utilisez des nonces ou des hachages pour les scripts et styles en ligne : Si vous devez utiliser des scripts ou des styles en ligne, utilisez des nonces ou des hachages pour autoriser des blocs de code spécifiques.
• Surveillez les violations de CSP : Utilisez la directive report-uri ou report-to pour surveiller les violations de CSP et ajuster votre politique en conséquence.
• Testez minutieusement : Utilisez l'en-tête Content-Security-Policy-Report-Only pour tester votre politique avant de la déployer en production.
• Itérez et affinez : La CSP n'est pas une configuration unique. Surveillez et affinez continuellement votre politique pour vous adapter aux changements de votre application et au paysage des menaces.

Qu'est-ce que le Cross-Origin Resource Sharing (CORS) ?

Le Cross-Origin Resource Sharing (CORS) est un mécanisme qui permet aux pages web d'une origine (domaine) d'accéder à des ressources d'une origine différente. Par défaut, les navigateurs appliquent une Same-Origin Policy, qui empêche les scripts de faire des requêtes vers une origine différente de celle d'où provient le script. Le CORS offre un moyen de relâcher sélectivement cette restriction, permettant les requêtes cross-origin légitimes tout en se protégeant contre les attaques malveillantes.

Comprendre la Same-Origin Policy

La Same-Origin Policy est un mécanisme de sécurité fondamental qui empêche un script malveillant d'un site web d'accéder à des données sensibles sur un autre site web. Une origine est définie par le schéma (protocole), l'hôte (domaine) et le port. Deux URL ont la même origine si et seulement si elles ont le même schéma, le même hôte et le même port.

Par exemple :

• https://www.example.com/app1/index.html et https://www.example.com/app2/index.html ont la même origine.
• https://www.example.com/index.html et http://www.example.com/index.html ont des origines différentes (schéma différent).
• https://www.example.com/index.html et https://sub.example.com/index.html ont des origines différentes (hôte différent).
• https://www.example.com:8080/index.html et https://www.example.com:80/index.html ont des origines différentes (port différent).

Comment fonctionne le CORS

Lorsqu'une page web effectue une requête cross-origin, le navigateur envoie d'abord une requête "preflight" au serveur. La requête preflight utilise la méthode HTTP OPTIONS et inclut des en-têtes qui indiquent la méthode HTTP et les en-têtes que la requête réelle utilisera. Le serveur répond ensuite avec des en-têtes qui indiquent si la requête cross-origin est autorisée.

Si le serveur autorise la requête, il inclut l'en-tête Access-Control-Allow-Origin dans la réponse. Cet en-tête spécifie les origines qui sont autorisées à accéder à la ressource. Le navigateur poursuit ensuite avec la requête réelle. Si le serveur n'autorise pas la requête, il n'inclut pas l'en-tête Access-Control-Allow-Origin, et le navigateur bloque la requête.

En-têtes CORS : Un examen détaillé

Le CORS repose sur des en-têtes HTTP pour communiquer entre le navigateur et le serveur. Voici les principaux en-têtes CORS :

• Access-Control-Allow-Origin : Spécifie les origines autorisées à accéder à la ressource. Cet en-tête peut contenir une origine spécifique (par exemple, https://www.example.com), un joker (*), ou null. L'utilisation de * autorise les requêtes de n'importe quelle origine, ce qui n'est généralement pas recommandé pour des raisons de sécurité. L'utilisation de `null` est appropriée uniquement pour les "réponses opaques" telles que lorsque la ressource est récupérée via le protocole `file://` ou un URI de données.
• Access-Control-Allow-Methods : Spécifie les méthodes HTTP autorisées pour la requête cross-origin (par exemple, GET, POST, PUT, DELETE).
• Access-Control-Allow-Headers : Spécifie les en-têtes HTTP autorisés dans la requête cross-origin. Ceci est important pour gérer les en-têtes personnalisés.
• Access-Control-Allow-Credentials : Indique si le navigateur doit inclure des informations d'identification (par exemple, cookies, en-têtes d'autorisation) dans la requête cross-origin. Cet en-tête doit être défini sur true pour autoriser les informations d'identification.
• Access-Control-Expose-Headers : Spécifie quels en-têtes peuvent être exposés au client. Par défaut, seul un ensemble limité d'en-têtes est exposé.
• Access-Control-Max-Age : Spécifie la durée maximale (en secondes) pendant laquelle le navigateur peut mettre en cache la requête preflight.
• Origin : Il s'agit d'un en-tête de requête envoyé par le navigateur pour indiquer l'origine de la requête.
• Vary : Un en-tête HTTP général, mais important pour le CORS. Lorsque `Access-Control-Allow-Origin` est généré dynamiquement, l'en-tête `Vary: Origin` doit être inclus dans la réponse pour indiquer aux mécanismes de mise en cache que la réponse varie en fonction de l'en-tête de requête `Origin`.

Exemples pratiques de CORS

Jetons un œil à quelques exemples pratiques de configurations CORS :

Exemple 1 : Autoriser les requêtes d'une origine spécifique

Cette configuration autorise les requêtes uniquement depuis https://www.example.com :

            Access-Control-Allow-Origin: https://www.example.com
            

              
                Copy
              
            
          

Exemple 2 : Autoriser les requêtes de n'importe quelle origine (non recommandé)

Cette configuration autorise les requêtes de n'importe quelle origine. À utiliser avec prudence car cela peut introduire des risques de sécurité :

            Access-Control-Allow-Origin: *
            

              
                Copy
              
            
          

Exemple 3 : Autoriser des méthodes et des en-têtes spécifiques

Cette configuration autorise les méthodes GET, POST et PUT, ainsi que les en-têtes Content-Type et Authorization :

            Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
            

              
                Copy
              
            
          

Exemple 4 : Autoriser les informations d'identification

Pour autoriser les informations d'identification (par exemple, les cookies), vous devez définir Access-Control-Allow-Credentials sur true et spécifier une origine spécifique (vous ne pouvez pas utiliser * lors de l'autorisation des informations d'identification) :

            Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Credentials: true
            

              
                Copy
              
            
          

Vous devez également définir credentials: 'include' dans votre requête fetch/XMLHttpRequest JavaScript.

            fetch('https://api.example.com/data', {
  credentials: 'include'
})
            

              
                Copy
              
            
          

Requêtes Preflight CORS

Pour certains types de requêtes cross-origin (par exemple, les requêtes avec des en-têtes personnalisés ou des méthodes autres que GET, HEAD ou POST avec Content-Type de application/x-www-form-urlencoded, multipart/form-data ou text/plain), le navigateur envoie une requête preflight utilisant la méthode OPTIONS. Le serveur doit répondre à la requête preflight avec les en-têtes CORS appropriés pour indiquer si la requête réelle est autorisée.

Voici un exemple de requête et de réponse preflight :

Requête Preflight (OPTIONS) :

            OPTIONS /data HTTP/1.1
Origin: https://www.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type, Authorization
            

              
                Copy
              
            
          

Réponse Preflight (200 OK) :

            HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400
            

              
                Copy
              
            
          

L'en-tête Access-Control-Max-Age spécifie la durée pendant laquelle le navigateur peut mettre en cache la réponse preflight, réduisant ainsi le nombre de requêtes preflight.

CORS et JSONP

JSON with Padding (JSONP) est une technique plus ancienne pour contourner la Same-Origin Policy. Cependant, JSONP présente des risques de sécurité importants et doit être évité au profit du CORS. JSONP repose sur l'injection de balises <script> dans la page, ce qui peut exécuter du code arbitraire. Le CORS offre un moyen plus sûr et plus flexible de gérer les requêtes cross-origin.

Bonnes pratiques pour le CORS

• Évitez d'utiliser * : Évitez d'utiliser le joker (*) dans l'en-tête Access-Control-Allow-Origin, car il autorise les requêtes de n'importe quelle origine. Spécifiez plutôt l'origine spécifique autorisée à accéder à la ressource.
• Soyez spécifique avec les méthodes et les en-têtes : Spécifiez les méthodes HTTP et les en-têtes exacts autorisés dans les en-têtes Access-Control-Allow-Methods et Access-Control-Allow-Headers.
• Utilisez Access-Control-Allow-Credentials avec prudence : N'activez Access-Control-Allow-Credentials que si vous avez besoin d'autoriser les informations d'identification (par exemple, les cookies) dans les requêtes cross-origin. Soyez conscient des implications de sécurité de l'autorisation des informations d'identification.
• Sécurisez vos requêtes preflight : Assurez-vous que votre serveur gère correctement les requêtes preflight et renvoie les en-têtes CORS corrects.
• Utilisez HTTPS : Utilisez toujours HTTPS à la fois pour l'origine et pour les ressources auxquelles vous accédez cross-origin. Cela aide à se protéger contre les attaques de type man-in-the-middle.
• Vary: Origin : Si vous générez dynamiquement l'en-tête `Access-Control-Allow-Origin`, incluez toujours l'en-tête `Vary: Origin` pour éviter les problèmes de mise en cache.

CSP et CORS en pratique : une approche combinée

Bien que la CSP et le CORS traitent tous deux des problèmes de sécurité, ils fonctionnent à des couches différentes et offrent une protection complémentaire. La CSP se concentre sur la prévention du chargement de contenu malveillant par le navigateur, tandis que le CORS se concentre sur le contrôle des origines qui peuvent accéder aux ressources sur votre serveur.

En combinant la CSP et le CORS, vous pouvez créer une posture de sécurité plus robuste pour vos applications web. Par exemple, vous pouvez utiliser la CSP pour restreindre les sources à partir desquelles les scripts peuvent être chargés, et le CORS pour contrôler quelles origines peuvent accéder à vos points d'API.

Exemple : Sécuriser une API avec CSP et CORS

Supposons que vous ayez une API hébergée sur https://api.example.com que vous souhaitez rendre accessible uniquement depuis https://www.example.com. Vous pouvez configurer votre serveur pour renvoyer les en-têtes suivants :

En-têtes de réponse API (https://api.example.com) :

            Access-Control-Allow-Origin: https://www.example.com
Content-Type: application/json
            

              
                Copy
              
            
          

Et vous pouvez configurer votre site web (https://www.example.com) pour utiliser l'en-tête CSP suivant :

En-tête CSP du site web (https://www.example.com) :

            Content-Security-Policy: default-src 'self'; script-src 'self'; connect-src 'self' https://api.example.com;
            

              
                Copy
              
            
          

Cette politique CSP permet au site web de charger des scripts et de se connecter à l'API, mais l'empêche de charger des scripts ou de se connecter à d'autres domaines.

Conclusion

La Content Security Policy (CSP) et le Cross-Origin Resource Sharing (CORS) sont des outils essentiels pour renforcer la sécurité de vos applications frontend. En configurant soigneusement la CSP et le CORS, vous pouvez réduire considérablement le risque d'attaques XSS, d'attaques par injection de données et d'autres vulnérabilités de sécurité. N'oubliez pas de commencer par une politique restrictive, de tester minutieusement et de surveiller et affiner continuellement votre configuration pour vous adapter aux changements de votre application et au paysage évolutif des menaces. En donnant la priorité à la sécurité frontend, vous pouvez protéger vos utilisateurs et assurer l'intégrité de vos applications web dans le monde numérique de plus en plus complexe d'aujourd'hui.