Différence entre les en-têtes de sécurité CORS et CSP Nyomtatás

  • 1

Le partage des ressources Cross Origin (CORS) et la politique de sécurité du contenu (CSP) sont des en-têtes de réponse HTTP qui, une fois mis en œuvre, contribuent à améliorer la sécurité d'une application Web.

Les deux en-têtes de sécurité permettent aux propriétaires d'applications de mettre en liste blanche l'origine des ressources dans leur application Web.

Les deux en-têtes de sécurité semblent fonctionner de manière similaire, mais ils ne fonctionnent pas réellement comme telle.

 

CORS

CORS est un en-tête HTTP indiquant votre politique concernant les sites souhaitant utiliser vos ressources directement depuis un autre nom de domaine, via des méthodes comme XMLHttpRequest.

Par exemple, supposons que l’on veuille mettre en place un CDN avec quelques bibliothèques JavaScript à disposition. Il faudra que, sur ce CDN, soit spécifié qui a le droit d’accéder à ces fichiers.

Supposons que l’on autorise tout le monde, cela donnerait dans un htaccess :

Header set Access-Control-Allow-Origin "*"


Si l’on ne veut autoriser qu’un nom de domaine particulier à utiliser ces ressources :

Access-Control-Allow-Origin: https://sub.domain.com

 

CSP - Content Security Policy

Attention, sauf si vous êtes sur un environnement de développement où vous pouvez vous permettre toutes les bêtises que vous voulez, un conseil : ne déployez pas CSP à l’aveuglette avec la fleur au fusil. Ne le faites jamais, car vous risquez de très vite déchanter.

CSP est un en-tête HTTP dont le principe est simple : vous envoyez des directives de sécurité au navigateur pour vos sources de contenus et vos éléments front-end, et ce dernier va se charger de les appliquer à la lettre.

L’idée de base de CSP est de réduire la surface d’attaque face aux attaques de type XSS. En pratique, CSP permet d’aller beaucoup plus loin et offre d’énormes possibilités : outils, connaissances et surveillance de votre front-end.

Nous n’allons pas tout détailler ici, il y aurait de quoi écrire un roman :)

Voici un exemple d’en-tête envoyé via PHP :

header("Content-Security-Policy: <ici vos directives>");

Voici quelques exemples de directives :

default-src 'self' ;

default-src sera la directive appliquée si aucune directive n’est définie pour un élément. Le mot-clé self indique que tout ce qui sera sur le même port, même protocole et même nom de domaine sera autorisé.

script-src 'self' www.google-analytics.com ;


Dans cet exemple, la directive script-src indique donc self, et également que tous les fichiers JavaScript provenant de www.google-analytics.com seront autorisés à s’exécuter.

img-src 'self' data: ;


Cette directive img-src indique également self, le mot-clé data: autorise quant à lui les contenus dit embarqués (via data-uri).

 

Report-only

Comme vu précédemment, un des soucis de CSP est son côté binaire : on l’active… ou non. Une possibilité vient résoudre ce problème : Report-only.

Comme son nom l’indique, on va indiquer au navigateur de seulement rapporter les erreurs générées par les directives spécifiées, sans bloquer quoi que ce soit côté navigateur.

header("Content-Security-Policy-Report-Only: <vos directives>");


Hasznosnak találta ezt a választ?

« Vissza

Powered by WHMCompleteSolution