Header CSP : la quasi-impossibilité de sa mise en oeuvre sur WordPress
22 février 2018
Captainigloo m’a fait part que, pour un expert en sécurité informatique ou cybersécurité, j’étais tout de même une tanche ! Il faut dire qu’il m’a infligé un coup fatal, en m’indiquant que mon site était un site de classe B au regard du site securityheaders.io. Alors, j’ai voulu le rassurer et surtout lui faire plaisir en le passant immédiatement en A. Rien que pour ça, il doit en être remercié. Pour le A+, en revanche, mon Capitaine Igloo dont le site est en D, c’est tout juste impossible !
Header Content Security Policy
L’entête CSP Content Security Policy a été conçu pour garantir à l’internaute qu’il visionnait bien les contenus du site sur lequel il naviguait. Dans l’hypothèse où un site se fait hacker, rien n’empêche alors de mettre dans les entêtes des pages du site la balise meta suivante :
<meta name="content-security-policy" content="default-src 'self' data: http: https: 'unsafe-inline' 'unsafe-eval'">
Tu parles d’une protection ?!
Si le hacker accède au fichier de configuration du serveur Web Apache, alors il peut ajouter dans la configuration générale la ligne suivante :
Header always set Content-Security-Policy "default-src 'self' data: http: https: 'unsafe-inline' 'unsafe-eval' ;"
Comment sur un site WordPress, truffé de plugins, de scripts « inline » utilisant à l’occasion la fonction eval, le Content Security Policy pourrait-il s’appliquer ? Pour un site de e-Commerce, c’est une toute autre histoire et il faudrait, de mon point de vue, se donner vraiment la peine de configurer le header CSP avec soin.