Refusé de charger le script car il enfreint la directive suivante relative à la politique de sécurité du contenu
Bonjour, lorsque j'ai essayé de déployer mon application sur des appareils dotés d'un système Android supérieur à la version 5.0.0, j'ai continué à recevoir ce genre de messages d'erreur:
07-03 18: 39: 21.621: D/SystemWebChromeClient (9132): file: ///Android_asset/www/index.html: Ligne 0: Refus de charger le fichier script ' http: // xxxxx ' car il enfreint le contenu suivant Directive de politique de sécurité: "script-src 'self' 'unsafe-eval' 'Unsafe-inline'". 07-03 18: 39: 21.621: I/chrome (9132): [INFO: CONSOLE (0)] "Refus de charger le script ' http: // xxx ' car il viole la directive de politique de sécurité du contenu suivante:" script-src 'self' 'unsafe-eval' 'unsafe-inline' ".
Cependant, si je l'ai déployé sur un appareil mobile avec le système Android 4.4.x, la stratégie de sécurité fonctionne avec les stratégies par défaut:
<meta http-equiv="Content-Security-Policy" content="default-src 'self' data: gap: https://ssl.gstatic.com 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; media-src *">
Alors j'ai pensé, peut-être, que je devrais changer pour quelque chose comme ceci:
<meta http-equiv="Content-Security-Policy" content="script-src 'self' 'unsafe-eval' 'unsafe-inline'; object-src 'self'; style-src 'self' 'unsafe-inline'; media-src *">
Fondamentalement, les deux options ne fonctionnent pas pour moi. Quelqu'un a-t-il une idée de la façon de résoudre ce problème?
Merci!
résolu avec
script-src 'self' http://xxxx 'unsafe-inline' 'unsafe-eval';
Essayez de remplacer votre balise META par celle ci-dessous:
<meta http-equiv="Content-Security-Policy" content="default-src *; style-src 'self' http://* 'unsafe-inline'; script-src 'self' http://* 'unsafe-inline' 'unsafe-eval'" />
Ou en plus de ce que vous avez, vous devriez ajouter http://* à la fois style-src et script-src comme vu ci-dessus, ajouté après 'self'
Si votre serveur inclut l'entête Content-Security-Policy, l'entête remplacera la méta.
La réponse automatique donnée par MagngooSasa a fait l'affaire, mais pour tous ceux qui essaient de comprendre la réponse, voici quelques détails supplémentaires:
Lors du développement de Cordova Apps avec Visual Studio, j'ai essayé d'importer un fichier javascript distant [situé ici http://Guess.What.com/MyScript.js] , mais l'erreur mentionnée dans le titre.
Voici la balise Meta AVANT, dans le fichier index.html du projet
<meta http-equiv="Content-Security-Policy" content="default-src 'self' data: gap: https://ssl.gstatic.com 'unsafe-eval'; style-src 'self' 'unsafe-inline'; media-src *">
Voici la balise META CORRECTED, pour permettre l’importation d’un script distant:
<meta http-equiv="Content-Security-Policy" content="default-src 'self' data: gap: https://ssl.gstatic.com 'unsafe-eval'; style-src 'self' 'unsafe-inline'; media-src *;**script-src 'self' http://onlineerp.solution.quebec 'unsafe-inline' 'unsafe-eval';** ">
et plus d'erreur!
Nous avons utilisé ceci:
<meta http-equiv="Content-Security-Policy" content="default-src gap://ready file://* *; style-src 'self' http://* https://* 'unsafe-inline'; script-src 'self' http://* https://* 'unsafe-inline' 'unsafe-eval'">
Pour en savoir plus sur cet ajout
script-src 'self' http://somedomain 'unsafe-inline' 'unsafe-eval';
À la balise méta comme
<meta http-equiv="Content-Security-Policy" content="default-src 'self' data: gap: https://ssl.gstatic.com 'unsafe-eval'; style-src 'self' 'unsafe-inline'; script-src 'self' https://somedomain.com/ 'unsafe-inline' 'unsafe-eval'; media-src *">
Corrige l'erreur
Pour ceux qui recherchent une explication complète, je vous recommande de consulter Politique de sécurité du contenu: https://www.html5rocks.com/en/tutorials/security/content-security-policy/ .
"Le code de https://mybank.com ne devrait avoir accès qu'aux données de Https://mybank.com et à https://evil.example.com devrait ne jamais être autorisé à accéder. Chaque origine est isolée du du reste du Web "
Les attaques XSS reposent sur l'incapacité du navigateur de distinguer le code de votre application de celui téléchargé depuis un autre site Web. Vous devez donc inclure dans la liste blanche les origines de contenu dont vous estimez pouvoir télécharger le contenu en toute sécurité, à l'aide de l'en-tête HTTP Content-Security-Policy.
Cette stratégie est décrite à l'aide d'une série de directives, chacune décrivant la stratégie pour un certain type de ressource ou domaine. Votre stratégie doit inclure une directive de stratégie default-src, qui constitue une solution de secours pour les autres types de ressources lorsqu'ils ne possèdent pas de stratégie.
Donc, si vous modifiez votre tag pour:
<meta http-equiv="Content-Security-Policy" content="default-src 'self' data: gap: https://ssl.gstatic.com 'unsafe-eval'; style-src 'self' 'unsafe-inline'; media-src *;**script-src 'self' http://onlineerp.solution.quebec 'unsafe-inline' 'unsafe-eval';** ">
Vous dites que vous autorisez l'exécution du code Javacsript (script-src) À partir des origines 'self', http://onlineerp.solution.quebec, 'unsafe-inline', 'unsafe-eval'.
Je suppose que les deux premiers sont parfaitement valables pour votre cas d'utilisation, je suis un peu incertain pour les autres. 'unsafe-line' et 'unsafe-eval' posent un problème de sécurité, vous ne devriez donc pas les utiliser à moins d'en avoir un besoin très spécifique:
"Si eval et ses frères text-to-JavaScript sont absolument essentiels à votre application, vous pouvez les activer en ajoutant 'unsafe-eval' en tant que source Autorisée dans une directive script-src. Mais, encore une fois, veuillez ne pas . Interdire la possibilité d'exécuter des chaînes rend beaucoup plus difficile pour un attaquant d'exécuter du code non autorisé sur votre site. " (Mike West, Google)
L'ajout d'une balise méta pour ignorer cette stratégie ne nous a pas aidés, car notre serveur Web injecte l'en-tête Content-Security-Policy dans la réponse.
Dans notre cas, nous utilisons Ngnix comme serveur Web pour les applications Java basées sur Tomcat9. Depuis le serveur Web, le navigateur n'autorise pas inline scripts. Par conséquent, pour un test temporaire, nous avons désactivé Content-Security-Policy en le commentant.
Comment désactiver ngnix?
Par défaut, ngnix ssl.conf aura cet ajout d'en-tête à la réponse.
#> grep 'Content-Security' -ir /etc/nginx/global/ssl.conf add_header Content-Security-Policy "default-src 'none'; frame-ancestors 'none'; script-src 'self'; img-src 'self'; style-src 'self'; base-uri 'self'; form-action 'self';";Si vous ne commentez que cette ligne et redémarrez ngnix, cela ne devrait pas être d'ajouter un en-tête à la réponse.
Si vous êtes préoccupé par la sécurité ou la production, veuillez ne pas suivre ceci. Utilisez ces étapes uniquement à des fins de test et de suivi.