Ressources pour développeur web

Théme de la semaine : OSINT

CSP : sécurisez votre site web avec .htaccess et PHP

Temps de lecture estimé : 6 minutes
Accueil PHP 8 CSP : sécurisez votre site web avec .htaccess et PHP

Vous avez peut-être déjà entendu parler de failles comme le XSS sans vraiment savoir comment vous en protéger. Une simple ligne mal sécurisée peut suffire à compromettre tout votre site : scripts injectés, données volées, visiteurs redirigés vers des sites douteux…Heureusement, il existe une solution puissante et accessible : la CSP (Content Security Policy)

  • Comprendre enfin comment fonctionne la CSP pour protéger efficacement votre site contre les scripts malveillants et les attaques invisibles
  • Savoir mettre en place une sécurité solide avec .htaccess ou PHP sans casser le fonctionnement de votre site
  • Éviter les erreurs courantes et configurer votre CSP pour qu’elle protège vraiment… sans bloquer vos fonctionnalités essentielles

Dans ce guide complet, vous allez comprendre comment la CSP fonctionne, à quoi elle sert, et surtout comment la mettre en place facilement avec .htaccess et PHP, même si vous débutez.

Qu’est-ce que la CSP (Content Security Policy) ?

La Content Security Policy (CSP) est un mécanisme de sécurité intégré aux navigateurs modernes. Son rôle est simple : contrôler ce que votre site a le droit de charger et d’exécuter.

Autrement dit, vous allez définir des règles du type :

“Mon site peut charger du JavaScript uniquement depuis mon serveur, et rien d’autre.”

CSP : Content Security Policy

Ainsi, si un pirate tente d’injecter un script malveillant… le navigateur le bloque automatiquement.

À quoi sert réellement la CSP ?

La CSP agit donc comme un garde du corps numérique pour votre site.

Sans CSP :

  • Votre site fait confiance à tout ce qu’il reçoit
  • Un script injecté peut s’exécuter librement

Avec CSP :

  • Vous définissez une liste blanche (whitelist) de sources autorisées
  • Tout le reste est bloqué

De quoi la CSP vous protège ?

La CSP est particulièrement efficace contre plusieurs types d’attaques :

1. Les attaques XSS (Cross-Site Scripting)

C’est l’attaque la plus courante.

Un pirate injecte du JavaScript dans votre site (via un formulaire, une URL, etc.). Si votre site n’est pas protégé, ce script peut :

  • voler des cookies
  • rediriger vos visiteurs
  • injecter du contenu malveillant

Avec une CSP bien configurée, ce script est bloqué.

👉 Pour aller plus loin, détecter vos failles XSS avec DalFox ou Owasp Zap.

2. Le chargement de ressources malveillantes

Sans CSP, votre site peut charger :

  • des scripts externes inconnus
  • des images ou iframes dangereuses

Avec CSP :

  • vous autorisez uniquement vos sources de confiance

3. Les injections de contenu tiers

Prenons un exemple concret : Vous utilisez une librairie externe… mais elle est compromise.

  • La CSP limite les dégâts en empêchant certains comportements dangereux.

Comment fonctionne une Content Security Policy ?

La CSP fonctionne via un header HTTP envoyé au navigateur. Ce header contient des règles appelées directives.

Exemple simple :

Content-Security-Policy: default-src 'self';

Traduction de cette CSP : Autorise uniquement les ressources venant de votre propre domaine.

👉 Pour aller encore plus loin dans la sécurisation : Sécuriser les Header HTTP en PHP

Mettre en place une CSP avec .htaccess

Si vous êtes sur un serveur Apache (comme souvent chez Ionos), vous pouvez ajouter votre CSP directement dans le fichier .htaccess.

Voici un exemple basique de son utilisation :

<IfModule mod_headers.c>
Header set Content-Security-Policy "default-src 'self';"
</IfModule>
  • Header set → ajoute un header HTTP
  • Content-Security-Policy → nom du header
  • 'self' → votre propre domaine

Mettre en place une CSP avec PHP

Si vous préférez gérer cela dynamiquement, vous pouvez le faire également en PHP.

Attention, ce code doit etre placé avant tout code HTML ou même un « espace ». Aucun caractère avant ce header :

<?php
header("Content-Security-Policy: default-src 'self'");

À placer donc en haut de vos fichiers PHP, avant tout affichage.

Depuis Wordpress, procéder depuis le fichier functions.php. Dans votre thème (ou thème enfant) :

add_action('send_headers', function() {
    header("Content-Security-Policy: default-src 'self';");
});

Pourquoi utiliser PHP ?

  • Permet une configuration dynamique
  • Utile pour adapter selon l’environnement
  • Idéal pour les frameworks ou CMS

Comprendre les directives principales de la CSP

C’est ici que les choses deviennent vraiment intéressantes. Une CSP est composée de directives qui définissent les règles.

default-src

Directive principale.

default-src 'self';

Règle globale pour toutes les ressources.

script-src

Contrôle le JavaScript.

script-src 'self' https://cdn.jsdelivr.net;

Cela autorise :

  • votre site
  • jsDelivr

Vous pouvez ajouter autant de permissions que nécessaire.

style-src

De la même façon que pour les fichiers javascript, cette fois pour les CSS.

style-src 'self' 'unsafe-inline';

⚠️ 'unsafe-inline' autorise le CSS inline (à éviter si possible)

img-src

Pour les images.

img-src 'self' data:;

data: permet les images en base64

Formation web et informatique - Alban Guillier - Formateur

Des formations informatique pour tous !

Débutant ou curieux ? Apprenez le développement web, le référencement, le webmarketing, la bureautique, à maîtriser vos appareils Apple et bien plus encore…

Formateur indépendant, professionnel du web depuis 2006, je vous accompagne pas à pas et en cours particulier, que vous soyez débutant ou que vous souhaitiez progresser. En visio, à votre rythme, et toujours avec pédagogie.

Découvrez mes formations Qui suis-je ?

connect-src (important pour AJAX)

Très important pour vos appels AJAX.

connect-src 'self' https://api.monsite.com;

Sans ça, vos requêtes AJAX peuvent être bloquées.

frame-src

Pour les iframes.

frame-src https://www.youtube.com;

font-src

Pour les polices.

font-src 'self' https://fonts.gstatic.com;

Exemple de CSP complète

Voici une CSP réaliste :

Header set Content-Security-Policy "
default-src 'self';
script-src 'self' https://cdn.jsdelivr.net;
style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
font-src 'self' https://fonts.gstatic.com;
img-src 'self' data:;
connect-src 'self';
frame-src https://www.youtube.com;
"

Cette configuration est déjà solide pour un site classique. À vous de l’adapter suivants vos besoins et contraintes.

Attention aux erreurs et pièges classiques

C’est souvent ici que tout casse… et que vous commencez à paniquer 😅

1. Bloquer ses propres scripts

Si vous oubliez d’autoriser :

  • votre CDN
  • vos scripts inline

Votre site peut ne plus fonctionner correctement, élargissez certaines permissions.

2. Le problème des scripts inline

Par défaut, la CSP bloque :

<script>alert('test');</script>

👉 Solutions :

  • utiliser des fichiers JS externes (recommandé)
  • ou ajouter 'unsafe-inline' (moins sécurisé)

3. Les frameworks JS

Certains frameworks utilisent :

  • eval()
  • inline scripts

Il faudra adapter votre CSP

4. Ne pas bloquer ses requêtes AJAX ?

C’est une question très importante. Si vos appels AJAX ne fonctionnent plus, c’est presque toujours à cause de :

connect-src

Si vous avez un appel AJAX tel que :

fetch("https://api.monsite.com/data")

Il vous faut alors autoriser :

connect-src 'self' https://api.monsite.com;

Le cas de WordPress ou d’une API externe

Si vous utilisez :

  • API REST WordPress
  • Stripe
  • Google Analytics

Il faut ajouter leurs domaines dans connect-src. Si vous ne les autorisez pas, ils seront bloqués.

Comment tester sa CSP efficacement ?

Mettre une CSP sans la tester… c’est comme installer une alarme sans vérifier qu’elle fonctionne.

1. Mode Report-Only (indispensable)

Avant d’activer la CSP, utilisez :

Header set Content-Security-Policy-Report-Only "default-src 'self';"

Cela fait que le navigateur :

  • ne bloque rien
  • mais affiche les erreurs dans la console

2. Console navigateur

Ouvrez :

  • clic droit → Inspecter
  • onglet Console

Vous verrez des messages comme :

Refused to load script because it violates CSP

👉 Tout savoir sur l’inspecteur et les Chrome dev tools.

3. Outils en ligne

Vous pouvez utiliser :

4. Logs côté serveur

Vous pouvez aussi configurer :

report-uri /csp-report-endpoint

Pour recevoir les erreurs côté serveur

Astuce : construire sa CSP progressivement

Ne cherchez pas à tout sécuriser d’un coup.

Faites plutôt :

  1. une CSP simple
  2. activez le mode report-only
  3. corrigez les erreurs
  4. renforcez progressivement

Exemple réel : sécuriser un site WordPress

Sur un site Sous Wordpress, la CSP pourra ressembler à ceci :

Header set Content-Security-Policy "
default-src 'self';
script-src 'self' 'unsafe-inline' https://www.googletagmanager.com;
style-src 'self' 'unsafe-inline';
img-src 'self' data:;
connect-src 'self';
"

Puis vous affinez selon vos plugins.


Mettre en place une Content Security Policy (CSP), ce n’est pas juste “ajouter une ligne de sécurité”. C’est reprendre le contrôle sur ce que votre site accepte ou refuse. Et dans un web où les attaques sont de plus en plus discrètes, cette maîtrise fait toute la différence.

Prenez le temps de la tester, de la comprendre, de l’ajuster. Oui, vous allez sûrement casser deux ou trois trucs au début… et c’est normal. Mais une fois en place, votre site devient bien plus robuste, et vous gagnez en sérénité.

Et entre nous… mieux vaut passer une heure à configurer une CSP que plusieurs jours à réparer un site piraté.