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

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>");

  • 0 Utilisateurs l'ont trouvée utile
Cette réponse était-elle pertinente?

Articles connexes

Wordpress xmlrpc DDoS

A inclure dans votre Htaccess ou dans le pre virtualhost Apache : <Filesxmlrpc.php> Order...

Memchached security - nos recommandations

ObjectifMemcached est un service de base de données en mémoire qui est principalement utilisé...

Cpanel - ConfigServer ModSecurity Control (cmc)

Petit topic suite à un cas particulier rencontré ce jour ! En complément du très connu...

CSP - Refused to [...] because it violates the following Content Security Policy directive

Vous avez une erreur de type :   Refused to apply inline style ... Refused to load the...

CPanel - Bloquer un pays tout entier via CSF et la GeoIP

Comment bloquer un pays entier via CSF   Si vous remarquez de nombreuses visites sur...

Powered by WHMCompleteSolution