Cette page a été traduite par l'API Cloud Translation.

Content Security Policy

Mike West

Joe Medley

Le modèle de sécurité du Web trouve sa racine règle de même origine. Coder provenant de https://mybank.com ne devraient avoir accès qu'aux membres de https://mybank.com données, et l'accès à https://evil.example.com ne doit certainement jamais être autorisé. Chaque origine est isolée du reste du Web, offrant ainsi aux développeurs un environnement sécurisé un bac à sable dans lequel construire et jouer. En théorie, c'est tout à fait génial. Dans pratique, les attaquants ont trouvé des moyens astucieux de renverser le système.

Script intersites (XSS) par exemple, contournent la même règle d'origine en trompant un site la diffusion de code malveillant en même temps que le contenu souhaité. Il s'agit d'une énorme car les navigateurs considèrent que tout le code affiché sur une page fait partie intégrante de l'origine de sécurité de cette page. La Aide-mémoires XSS est un échantillon ancien mais représentatif des méthodes qu’un attaquant pourrait utiliser de violer cette confiance en injectant du code malveillant. Si un attaquant réussit injecte n'importe quel code, la partie est presque terminée: les données de session utilisateur compromises et des informations qui doivent rester secrètes sont exfiltrées vers The Bad Les mec. Nous essaierons évidemment de les éviter si possible.

Cette vue d’ensemble met en évidence une défense qui peut réduire considérablement le risque et impact des attaques XSS dans les navigateurs modernes: Content Security Policy (CSP).

TL;DR

Utilisez des listes d'autorisation pour indiquer au client ce qui est autorisé et ce qui ne l'est pas.
Découvrez les directives disponibles.
Identifiez les mots clés qu'ils utilisent.
Le code intégré et les eval() sont considérés comme dangereux.
Signalez les cas de non-respect des règles à votre serveur avant de les appliquer.

Listes d'autorisation sources

Le problème exploité par les attaques XSS est l'incapacité du navigateur à distinguer entre le script qui fait partie de votre application et le script qui a été injectées de manière malveillante par un tiers. Par exemple, le bouton +1 de Google au bas de cette page charge et exécute le code https://apis.google.com/js/plusone.js dans le contexte de l'origine de cette page. Mer Ce code n'est pas fiable, mais le navigateur ne peut pas le détecter tout seul. Les avantages de apis.google.com sont extraordinaires, contrairement à ceux de apis.evil.example.com. ne l’est probablement pas. Le navigateur se contente de télécharger et d'exécuter le code d'une page de requêtes, quelle que soit leur source.

Au lieu de faire aveuglément confiance à tout ce qu'un serveur fournit, CSP définit le Content-Security-Policy, qui vous permet de créer une liste d'autorisation sources de contenu fiable, et demande au navigateur de n'exécuter ou d'afficher les ressources de ces sources. Même si un attaquant peut trouver un trou par lequel pour injecter un script, celui-ci ne correspond pas à la liste d'autorisation et n'est donc pas exécuté.

Nous comptons sur apis.google.com pour vous fournir du code valide et nous avons toute confiance pour faire de même, définissons une stratégie qui n'autorise l'exécution du script que lorsqu'il provient de l'une de ces deux sources:

Content-Security-Policy: script-src 'self' https://apis.google.com

Simple, n'est-ce pas ? Comme vous l'avez probablement deviné, script-src est une directive qui contrôle un ensemble de droits liés au script pour une page spécifique. Nous avons indiqué 'self' comme source de script valide et https://apis.google.com comme source de script une autre. Le navigateur télécharge et exécute correctement JavaScript depuis apis.google.com sur HTTPS, ainsi qu'à partir de l'origine de la page actuelle.

Erreur dans la console: chargement du script "http://evil.example.com/evil.js" refusé car il ne respecte pas la directive Content Security Policy suivante: script-src "self" https://apis.google.com

Lorsque cette stratégie est définie, le navigateur génère simplement une erreur au lieu de à partir de n'importe quelle autre source. Lorsqu’un attaquant intelligent parvient à injecter du code dans votre site, ils s'exécuteront directement dans un message d'erreur au lieu que le succès qu'ils espéraient.

Les règles s'appliquent à une grande variété de ressources

Si les ressources de script représentent les risques de sécurité les plus évidents, CSP offre ensemble d'instructions qui permettent de contrôler de manière assez précise les ressources lors du chargement d'une page. Comme vous avez déjà vu script-src, le concept doivent être claires.

Examinons rapidement les autres directives de la ressource. La liste ci-dessous représente l'état des directives à partir du niveau 2. Une spécification de niveau 3 a été publiée, mais n'est largement pas implémentée dans les principaux des navigateurs.

base-uri limite les URL qui peuvent apparaître dans l'élément <base> d'une page.
child-src répertorie les URL des nœuds de calcul et du contenu des frames intégrés. Pour exemple: child-src https://youtube.com activerait l'intégration de vidéos depuis YouTube, mais pas d'autres origines.
connect-src limite les origines auxquelles vous pouvez vous connecter (via XHR, WebSockets et EventSource).
font-src spécifie les origines pouvant diffuser les polices Web. Le site Web de Google les polices peuvent être activées via font-src https://themes.googleusercontent.com.
form-action répertorie les points de terminaison valides pour l'envoi à partir de balises <form>.
frame-ancestors spécifie les sources pouvant intégrer la page active. Cette directive s'applique aux tags <frame>, <iframe>, <embed> et <applet>. Cette instruction ne peut pas être utilisée dans les balises <meta> et ne s'applique qu'aux balises autres que HTML ressources.
frame-src est obsolète depuis le niveau 2, mais il est restauré au niveau 3. Si ce n'est pas le cas présente, elle revient toujours à child-src comme précédemment.
img-src définit les origines à partir desquelles les images peuvent être chargées.
media-src limite les origines autorisées à diffuser des contenus vidéo et audio.
object-src permet de contrôler Flash et d'autres plug-ins.
plugin-types limite les types de plug-ins qu'une page peut appeler.
report-uri indique l'URL à laquelle le navigateur envoie des rapports lorsqu'un règlement relatif à la sécurité du contenu n'a pas été respecté. Impossible d'utiliser cette directive dans <meta> .
style-src est l'équivalent de script-src pour les feuilles de style.
upgrade-insecure-requests demande aux user-agents de réécrire les schémas d'URL. en passant de HTTP à HTTPS. Cette directive concerne les sites Web possédant un grand nombre d'anciennes URL qui doivent être réécrites.
worker-src est une directive CSP de niveau 3 qui limite les URL pouvant être chargé en tant que nœud de calcul, nœud de calcul partagé ou service worker. Depuis juillet 2017, comporte implémentations limitées.

Par défaut, les directives sont largement ouvertes. Si vous ne définissez pas de règle spécifique pour d'après font-src, cette directive se comporte par défaut comme suit : alors que vous avez spécifié * comme source valide (par exemple, vous pouvez charger des polices n'importe où, sans restriction).

Vous pouvez ignorer ce comportement par défaut en spécifiant un default-src directive. Cette directive définit les valeurs par défaut que vous ne spécifiez pas. Généralement, cela s'applique à toute directive se termine par -src. Si default-src est défini sur https://example.com et que vous échouez pour spécifier une instruction font-src, vous pouvez charger des polices https://example.com, et nulle part ailleurs. Nous n'avons spécifié que script-src dans notre les exemples précédents, ce qui signifie que les images, les polices, etc. peuvent être chargées quelle que soit l'origine.

Les directives suivantes n'utilisent pas default-src comme solution de remplacement. N'oubliez pas que ne pas les définir revient à autoriser n'importe quoi.

base-uri
form-action
frame-ancestors
plugin-types
report-uri
sandbox

Vous pouvez utiliser autant d'instructions que nécessaire pour votre une application spécifique, en les répertoriant dans l'en-tête HTTP, avec des points-virgules. Assurez-vous de répertorier tous ressources requises d'un type spécifique dans une directive unique. Si vous avez écrit quelque chose comme script-src https://host1.com; script-src https://host2.com le deuxième directive serait tout simplement ignoré. Quelque chose comme ce qui suit fonctionnerait indiquer correctement les deux origines comme valides:

script-src https://host1.com https://host2.com

Par exemple, si l'une de vos applications charge toutes ses ressources à partir d'un réseau de diffusion de contenu (https://cdn.example.net, par exemple), et sachez que n'avez pas besoin de contenu encadré ni de plug-ins, vos règles peuvent ressembler comme suit:

Content-Security-Policy: default-src https://cdn.example.net; child-src 'none'; object-src 'none'

Détails de mise en œuvre

Vous verrez les en-têtes X-WebKit-CSP et X-Content-Security-Policy dans différentes des tutoriels sur le Web. À l'avenir, vous devez ignorer ces préfixes en-têtes. Les navigateurs récents (à l'exception d'IE) prennent en charge le sans préfixe En-tête Content-Security-Policy. C'est l'en-tête que vous devez utiliser.

Quel que soit l'en-tête que vous utilisez, la règle est définie page par page: vous devez envoyer l'en-tête HTTP avec chaque réponse que vous souhaitez sont protégées. Cela offre beaucoup de flexibilité, car vous pouvez ajuster les règles à appliquer à des pages spécifiques, en fonction de leurs besoins spécifiques. Peut-être un ensemble de pages de votre site comportent un bouton +1, contrairement aux autres pages. code du bouton à charger uniquement en cas de nécessité.

La liste source de chaque directive est flexible. Vous pouvez spécifier les sources schéma (data:, https:), ou avec une précision allant de "nom d'hôte uniquement" (example.com, qui correspond à n'importe quelle origine sur cet hôte: n'importe quel schéma, n'importe quel port) vers un URI complet (https://example.com:443, qui correspond uniquement à HTTPS, example.com et uniquement sur le port 443). Les caractères génériques sont acceptés, mais uniquement sous forme de schéma, un port, ou à la position la plus à gauche du nom d'hôte: *://*.example.com:* correspondre à tous les sous-domaines de example.com (mais pas example.com lui-même), avec quel que soit le schéma, sur n'importe quel port.

La liste source accepte également quatre mots clés:

Comme vous pouvez vous y attendre, 'none' ne correspond à rien.
'self' correspond à l'origine actuelle, mais pas à ses sous-domaines.
'unsafe-inline' permet d'intégrer le code JavaScript et CSS. (Nous y reviendrons dans dans un instant.)
'unsafe-eval' permet des mécanismes texte-vers-JavaScript tels que eval. (Nous vous à cela également.)

Ces mots clés doivent être entre guillemets simples. Par exemple, script-src 'self' (avec des guillemets) autorise l'exécution de JavaScript à partir de l'hôte actuel ; script-src self (sans guillemets) autorise JavaScript à partir d'un serveur nommé "self". (et non à partir du l'hôte actuel), ce qui n'est probablement pas ce que vous vouliez.

Bac à sable

Voici une autre directive qui mérite d'être évoquée: sandbox. C'est un peu différent des autres que nous avons examinés, car il impose des restrictions sur les actions la page peut prendre au lieu de ressources qu'elle peut charger. Si le l'instruction sandbox est présente, la page est traitée comme si elle avait été chargée ; dans un <iframe> avec un attribut sandbox. Cela peut avoir un large éventail effets sur la page: forcer la page à avoir une origine unique et empêcher l'affichage envoi, entre autres. Cela dépasse le cadre de cet article, mais vous pouvez trouver des informations complètes sur les attributs de bac à sable valides dans la "Bac à sable" de la spécification HTML5.

La balise Meta

Le mécanisme de distribution privilégié des CSP est un en-tête HTTP. Il peut toutefois être utile, pour définir une règle sur une page directement dans le balisage. Pour ce faire, utilisez une balise <meta> avec Un attribut http-equiv:

<meta
  http-equiv="Content-Security-Policy"
  content="default-src https://cdn.example.net; child-src 'none'; object-src 'none'"
/>

Vous ne pouvez pas l'utiliser pour frame-ancestors, report-uri ni sandbox.

Le code intégré est considéré comme dangereux

Il doit être clair que CSP est basé sur les origines de la liste d'autorisation, car il s'agit sans ambiguïté pour demander au navigateur de traiter des ensembles spécifiques de ressources et refuser les autres. Ce n'est pas le cas des listes d'autorisation basées sur l'origine. mais de résoudre la plus grande menace posée par les attaques XSS: l'injection de script intégré. Si un pirate informatique peut injecter un tag de script contenant directement des charge utile (<script>sendMyDataToEvilDotCom();</script>), le navigateur ne dispose d'aucun mécanisme permettant de le distinguer d'un serveur de script intégré. CSP résout ce problème en interdisant complètement le script intégré: c'est la seule façon d'en être sûr.

Cette interdiction concerne non seulement les scripts intégrés directement dans les balises script, mais aussi les gestionnaires d'événements intégrés et les URL javascript:. Vous devrez déplacer le contenu de script dans un fichier externe, et remplacez les URL javascript: et <a ... onclick="[JAVASCRIPT]"> par les appels addEventListener() appropriés. Par exemple : vous pouvez réécrire ce qui suit à partir de:

<script>
  function doAmazingThings() {
    alert('YOU AM AMAZING!');
  }
</script>
<button onclick="doAmazingThings();">Am I amazing?</button>

par quelque chose comme:

<!-- amazing.html -->
<script src="amazing.js"></script>
<button id="amazing">Am I amazing?</button>

<div style="clear:both;"></div>

// amazing.js
function doAmazingThings() {
  alert('YOU AM AMAZING!');
}
document.addEventListener('DOMContentLoaded', function () {
  document.getElementById('amazing').addEventListener('click', doAmazingThings);
});

Le code réécrit présente un certain nombre d'avantages en plus de bien fonctionner avec CSP; c'est déjà une bonne pratique, quelle que soit votre utilisation de CSP. Intégré JavaScript mélange la structure et le comportement exactement comme vous ne devriez pas le faire. Les ressources externes sont plus faciles à mettre en cache par les navigateurs, développeurs, et favorisent la compilation et la minimisation. Vous écrirez mieux si vous déplacez du code vers des ressources externes.

Le style intégré est traité de la même manière: l'attribut style et style les tags doivent être regroupés dans des feuilles de style externes pour empêcher une grande variété d'étonnamment astucieux méthodes d'exfiltration de données activées par CSS.

Si vous avez besoin d'un script et d'un style intégrés, vous pouvez les activer en ajoutant 'unsafe-inline' comme source autorisée dans un élément script-src ou style-src. directive. Vous pouvez également utiliser un nonce ou un hachage (voir ci-dessous), mais ce n'est absolument pas autorisé. L'exclusion d'un script intégré est la plus grande réussite en termes de sécurité fournie par CSP, et l'interdiction de style intégré renforce également votre application. C’est un peu pour s'assurer que tout fonctionne correctement une fois l'ensemble du code déplacé hors ligne, mais c'est un compromis qui en vaut la peine.

Si vous devez absolument l'utiliser

CSP de niveau 2 offre une rétrocompatibilité pour les scripts intégrés en vous permettant ajoutez des scripts intégrés spécifiques à la liste d'autorisation à l'aide d'un nonce cryptographique (nombre utilisé une fois) ou un hachage. Même si cela peut être fastidieux, en un clin d'œil.

Pour utiliser un nonce, attribuez un attribut nonce à votre tag de script. Sa valeur doit correspondre à un dans la liste des sources fiables. Exemple :

<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">
  // Some inline code I can't remove yet, but need to asap.
</script>

Ajoutez maintenant le nonce à votre directive script-src, en plus du mot clé nonce-.

Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'

Rappelez-vous que les nonces doivent être générés de nouveau pour chaque demande de page et doivent être impossible à deviner.

Les hachages fonctionnent à peu près de la même manière. Au lieu d'ajouter du code au tag de script, créer un hachage SHA du script lui-même et l'ajouter à la directive script-src. Par exemple, imaginons que votre page contienne les éléments suivants:

<script>
  alert('Hello, world.');
</script>

Votre politique doit contenir les éléments suivants:

Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='

Voici quelques points à noter. Le préfixe sha*- spécifie l'algorithme qui génère le hachage. Dans l'exemple ci-dessus, sha256- est utilisé. CSP a également accepte sha384- et sha512-. Lors de la génération du hachage, n'incluez pas la paire valeur/clé <script> tags. L'utilisation de minuscules/majuscules et les espaces blancs sont importants, y compris au début ou d'un espace blanc final.

Une recherche Google sur la génération de hachages SHA vous mènera à des solutions dans n'importe quelle un certain nombre de langues. À partir de la version 40 de Chrome, vous pouvez ouvrir les outils de développement, actualisez votre page. L'onglet "Console" contient des messages d'erreur avec le bon identifiant le hachage sha256 pour chacun de vos scripts intégrés.

Évaluer également

Même lorsqu’un attaquant ne peut pas injecter le script directement, il peut être en mesure de tromper votre application afin de convertir un texte inerte en code JavaScript exécutable et l'exécute en son nom. eval(), nouveau Function(), setTimeout([string], ...) et setInterval([string], ...) représentent tous les vecteurs à travers lesquels injectés texte pourrait finir par exécuter quelque chose de malveillant de manière inattendue. CSP par défaut la réponse à ce risque est de bloquer complètement tous ces vecteurs.

Cela a plusieurs conséquences sur la façon dont vous créez des applications:

Vous devez analyser JSON via l'JSON.parse intégré plutôt que de compter sur eval Les opérations JSON natives sont disponibles tous les navigateurs depuis IE8. en toute sécurité.
Réécrire tous les appels setTimeout ou setInterval que vous passez actuellement avec des fonctions intégrées plutôt que des chaînes. Exemple :

setTimeout("document.querySelector('a').style.display = 'none';", 10);

serait mieux écrit comme suit:

setTimeout(function () {
  document.querySelector('a').style.display = 'none';
}, 10);

Évitez les modèles intégrés au moment de l'exécution: de nombreuses bibliothèques de modèles utilisent généreusement new Function() pour accélérer la génération de modèles au moment de l'exécution. Il s'agit d'un une application astucieuse de la programmation dynamique, mais s'accompagne pour évaluer des textes malveillants. Certains frameworks sont directement compatibles avec CSP, en recourant à un analyseur fiable en l'absence de eval. Directive ng-csp d'AngularJS en est un bon exemple.

Cependant, un meilleur choix serait un langage de création de modèles qui offre la précompilation (Handlebars fait, par exemple). La précompilation de vos modèles peut rendre l'expérience utilisateur plus rapide que l'implémentation d'exécution la plus rapide, et il est également plus sûr. Si évaluation et et ses modèles texte-vers-JavaScript sont essentiels pour votre application, vous pouvez les activer en ajoutant 'unsafe-eval' comme source autorisée dans un script-src , mais nous vous déconseillons vivement de le faire. Interdire l'exécution rendent beaucoup plus difficile pour un attaquant d'exécuter sur votre site.

Rapports

La capacité de CSP à bloquer les ressources non approuvées côté client est un énorme avantage pour votre aux utilisateurs, mais il serait très utile d'avoir une notification sont renvoyés au serveur afin que vous puissiez identifier et corriger les bugs éventuels par injection malveillante. À cette fin, vous pouvez demander au navigateur pour signaler un cas de non-respect au format JSON à POST un établissement spécifié dans une instruction report-uri.

Content-Security-Policy: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

Ces rapports se présenteront comme suit:

{
  "csp-report": {
    "document-uri": "http://example.org/page.html",
    "referrer": "http://evil.example.com/",
    "blocked-uri": "http://evil.example.com/evil.js",
    "violated-directive": "script-src 'self' https://apis.google.com",
    "original-policy": "script-src 'self' https://apis.google.com; report-uri http://example.org/my_amazing_csp_report_parser"
  }
}

Il contient une bonne partie d'informations qui vous aideront à retrouver la cause spécifique de l'infraction, y compris la page concernée. (document-uri), l'URL de provenance de cette page (notez que, contrairement à en-tête, la clé n'est pas mal orthographiée), la ressource qui n'a pas respecté le règlement de la page (blocked-uri), la directive spécifique qu'elle ne respecte pas (violated-directive) et la règle complète de la page (original-policy).

Rapport uniquement

Si vous débutez avec CSP, il est judicieux d'évaluer la version actuelle l'état de votre application avant de déployer une stratégie draconienne auprès de vos utilisateurs. En tant que tremplin vers un déploiement complet, vous pouvez demander au navigateur une règle, signaler les cas de non-respect mais ne pas appliquer les restrictions. Au lieu de en envoyant un en-tête Content-Security-Policy, envoyez une Content-Security-Policy-Report-Only.

Content-Security-Policy-Report-Only: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

La règle spécifiée en mode rapport uniquement ne bloque pas les ressources limitées, Les signalements de non-respect sont envoyés à l'adresse que vous avez spécifiée. Vous pouvez même envoyer deux en-têtes, ce qui applique une règle tout en surveillant une autre. C'est un excellent d'évaluer l'effet des modifications apportées au CSP de votre application: activez signaler une nouvelle règle, surveiller les signalements de non-respect et corriger les bugs augmenter ; Lorsque vous êtes satisfait de son effet, commencez à l'appliquer.

Utilisation réelle

CSP 1 fonctionne bien dans Chrome, Safari et Firefox, mais présente de nombreuses la compatibilité avec Internet Explorer 10. Vous pouvez Pour en savoir plus, rendez-vous sur caniuse.com. CSP de niveau 2 est disponible dans Chrome depuis version 40. D'importants sites comme Twitter et Facebook ont déployé l'en-tête (l'étude de cas de Twitter vaut la peine d'être lue), et la norme est tout à fait prête. pour commencer à les déployer sur vos propres sites.

Pour élaborer une stratégie pour votre application, la première étape consiste à évaluer les ressources que vous chargez réellement. Une fois que vous pensez avoir une main sur la façon éléments sont compilés dans votre application, définissez une stratégie basée sur ces exigences. Passons en revue quelques cas d'utilisation courants et découvrons comment de les prendre en charge dans les zones de protection de CSP.

Cas d'utilisation n° 1: widgets de réseaux sociaux

Le bouton +1 de Google inclut un script de https://apis.google.com et intègre un <iframe> à partir de https://plusone.google.com Vous avez besoin d'une stratégie qui inclut à la fois pour intégrer le bouton. La règle minimale est script-src https://apis.google.com; child-src https://plusone.google.com. Vous devez également pour s'assurer que l'extrait de code JavaScript fourni par Google est extrait un fichier JavaScript externe. Si vous aviez une règle basée sur le niveau 1 utilisant frame-src Le niveau 2 exige que vous la remplaciez par child-src. Ce n'est plus nécessaire au niveau 3 de la CSP.
Bouton "J'aime" de Facebook propose différentes options d'implémentation. Nous vous recommandons de respecter le <iframe>, car elle est isolée du reste de votre site dans un bac à sable sécurisé. Il nécessite une directive child-src https://facebook.com pour fonctionner correctement. Remarque que, par défaut, le code <iframe> fourni par Facebook charge une valeur relative URL : //facebook.com. Modifiez cela pour spécifier explicitement HTTPS: https://facebook.com Il n'y a aucune raison d'utiliser HTTP si cela n'est pas nécessaire.
Bouton "Tweet" de Twitter repose sur l'accès à un script et à un frame, tous deux hébergés sur https://platform.twitter.com (Twitter fournit également une URL relative default; modifiez le code de manière à spécifier HTTPS lorsque vous le copiez/collez localement. Vous serez prêt à utiliser script-src https://platform.twitter.com; child-src https://platform.twitter.com, tant que vous déplacez l'extrait JavaScript que Twitter fournit dans un fichier JavaScript externe.
Les autres plates-formes ont des exigences similaires et peuvent être traitées de la même manière. Nous vous suggérons de définir une default-src sur 'none' et de regarder votre console pour déterminer les ressources que vous devez activer pour que les widgets fonctionnent.

L'inclusion de plusieurs widgets est simple: il vous suffit de combiner les règles directives, sans oublier de fusionner toutes les ressources d'un même type en un directive. Si vous vouliez les trois widgets de réseaux sociaux, la règle serait comme ceci:

script-src https://apis.google.com https://platform.twitter.com; child-src https://plusone.google.com https://facebook.com https://platform.twitter.com

Cas d'utilisation n° 2: blocage

Supposons un instant que vous gériez un site bancaire et que vous vouliez vous assurer seules les ressources que vous avez écrites vous-même peuvent être chargées. Dans ce scénario, commencez par une règle par défaut qui bloque absolument tout (default-src 'none'), puis créez-la à partir de là.

Imaginons que la banque charge l'ensemble des images, styles et scripts à partir d'un CDN https://cdn.mybank.net, et se connecte via XHR à https://api.mybank.com/ pour : extraire différentes données vers le bas. Les cadres sont utilisés, mais uniquement pour les pages locales (aucune origine tierce). Le site ne contient pas de contenu Flash, extras. L'en-tête CSP le plus restrictif que nous puissions envoyer est le suivant:

Content-Security-Policy: default-src 'none'; script-src https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net; connect-src https://api.mybank.com; child-src 'self'

Cas d'utilisation n° 3: SSL uniquement

Un administrateur d’un forum de discussion de mariage veut s’assurer que toutes les ressources sont ne sont chargés que via des canaux sécurisés, mais n’écrivent pas beaucoup de code ; réécriture de gros blocs du logiciel de forum tiers qui regorge de et son style lui dépassent ses capacités. La stratégie suivante serait efficace:

Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'

Même si https: est spécifié dans default-src, le script et le style n'héritent pas automatiquement de cette source. Chaque directive est totalement remplace la valeur par défaut pour ce type de ressource spécifique.

L'avenir

Le niveau 2 de Content Security Policy est un Recommandation concernant le candidat. Groupe de travail sur la sécurité des applications Web du W3C a déjà commencé à travailler sur la prochaine itération de la spécification, Content Security Policy Niveau 3.

Si vous êtes intéressé par la discussion sur ces fonctionnalités à venir, Passez en revue les archives de la liste de diffusion public-webappsec@, ou rejoindre vous-même.