CSP et scripts tiers : ce que Sentry, HubSpot et Algolia demandent

« This Content-Security-Policy directive is deprecated. » Ce genre d’avertissement, visible dans la console du navigateur, illustre bien la difficulté de configurer une politique de sécurité du contenu quand plusieurs services tiers cohabitent sur un même site : chacun a ses propres exigences de domaines, et une seule directive mal réglée bloque silencieusement une fonctionnalité entière, du suivi d’erreurs à la recherche instantanée.

La documentation de la spécification CSP, publiée par le groupe de travail du W3C et référencée sur MDN, explique le fonctionnement de chaque directive, mais ne dit rien des domaines précis qu’un service commercial donné utilise en coulisses. C’est cette information, dispersée entre les documentations respectives de Sentry, HubSpot et Algolia, qu’il faut rassembler pour construire une CSP qui protège réellement sans casser ces trois intégrations très répandues sur les sites WordPress d’entreprise.

Ce que demande chaque service, directive par directive

Une politique de sécurité du contenu se compose de plusieurs directives, chacune contrôlant une catégorie de ressources. Les trois services examinés ici sollicitent principalement trois directives différentes, ce qui explique pourquoi une CSP pensée pour un seul service en oublie souvent une autre en pratique :

• Sentry (suivi d’erreurs) a besoin de connect-src pour envoyer les événements capturés vers son ingestion, typiquement un sous-domaine du type *.ingest.sentry.io, en plus de script-src pour charger son SDK JavaScript si celui-ci n’est pas embarqué localement.
• HubSpot (CRM et formulaires) sollicite script-src pour son script de suivi principal hébergé sur js.hs-scripts.com, et frame-src dès qu’un formulaire HubSpot s’affiche en iframe plutôt qu’en intégration native.
• Algolia (recherche instantanée) utilise principalement connect-src pour ses appels d’API vers *.algolianet.com, la recherche elle-même se faisant en arrière-plan via des requêtes asynchrones plutôt que par chargement de script au moment de la frappe.

Construire l’en-tête sans ouvrir la politique à tout le web

La tentation, face à la complexité de ces trois exigences combinées, est d’utiliser un joker * sur une directive entière pour ne plus avoir à s’en soucier. C’est précisément ce que la CSP est censée empêcher : une politique qui autorise tout revient à ne pas en avoir. La bonne approche consiste à lister explicitement chaque domaine nécessaire :

function ajouter_en_tete_csp() {
    $politique = "default-src 'self'; " .
        "script-src 'self' https://js.hs-scripts.com https://browser.sentry-cdn.com; " .
        "connect-src 'self' https://*.algolianet.com https://*.algolia.net https://*.ingest.sentry.io; " .
        "frame-src 'self' https://forms.hubspot.com; " .
        "style-src 'self' 'unsafe-inline';";

    header( "Content-Security-Policy: {$politique}" );
}
add_action( 'send_headers', 'ajouter_en_tete_csp' );

Cette politique reste restrictive par défaut (default-src 'self') et n’ouvre que les domaines précis dont chaque service a réellement besoin, directive par directive. Le domaine Algolia illustre un point à vérifier systématiquement : les services tiers utilisent parfois plusieurs domaines apparentés (algolianet.com pour les requêtes de recherche, algolia.net pour certains points de terminaison d’administration), qu’il faut identifier via leur documentation officielle plutôt que deviner.

Passer par le mode report-only avant l’application stricte

Avant d’appliquer une CSP en mode bloquant, l’en-tête Content-Security-Policy-Report-Only permet d’observer, sans rien casser, quelles ressources auraient été bloquées par la politique envisagée :

header( "Content-Security-Policy-Report-Only: {$politique}" );

Le navigateur continue de charger toutes les ressources normalement, mais journalise chaque violation potentielle dans la console de développement. Cette étape intermédiaire, maintenue pendant une à deux semaines de navigation représentative, révèle les domaines oubliés avant qu’un blocage réel n’affecte les visiteurs du site en production.

Les pièges fréquents sur ces trois intégrations

• Oublier frame-src pour HubSpot quand un formulaire est intégré en iframe plutôt qu’en JavaScript natif : le script charge, mais le formulaire reste invisible.
• Restreindre connect-src à un seul sous-domaine Algolia alors que le SDK utilise plusieurs points de terminaison selon la région d’hébergement de l’index.
• Ajouter les domaines Sentry à script-src mais oublier connect-src, ce qui charge le SDK sans jamais lui permettre d’envoyer les événements capturés.

Une CSP qui ne bloque jamais rien en mode report-only n’a pas forcément raison d’être trop permissive : elle peut simplement signifier que le site n’a pas encore été suffisamment testé dans tous ses parcours.

Notion à retenir : une CSP se maintient dans le temps

Une politique de sécurité du contenu n’est jamais un réglage figé une fois pour toutes : l’ajout d’un nouveau service tiers, la migration d’un CDN ou un changement d’architecture d’un service existant peut introduire un nouveau domaine à déclarer. La documentation officielle du Content-Security-Policy sur MDN reste la référence à consulter pour chaque nouvelle directive ajoutée à la politique.

En résumé

Sentry, HubSpot et Algolia partagent un point commun malgré leurs usages très différents : chacun documente ses domaines d’infrastructure, mais aucun ne fournit de configuration CSP clé en main pour WordPress. Rassembler ces informations directive par directive, et valider en mode report-only avant application stricte, évite le choix par défaut le plus tentant et le plus dangereux : une politique de sécurité du contenu qui n’en est plus une.