Votre site a changé. Votre équipe le sait déjà.

Oui, ainsi que dans Microsoft Teams, Google Chat, Telegram, par e-mail ou vers n'importe quel webhook que vous hébergez. Connectez le canal une fois, puis dirigez-y vos règles. Une règle peut publier dans plusieurs canaux, et deux règles sur le même site peuvent atteindre des équipes différentes.

Les skimmers Magecart et de formjacking sont la raison. Bloquer, c'est le rôle de la Content Security Policy, et vous devriez en avoir une. Ce qu'une politique ne sait pas faire, c'est distinguer un bon changement d'un mauvais à l'intérieur d'un prestataire que vous avez déjà approuvé : c'est exactement ainsi que British Airways a été compromis. La politique ferme les portes ; les alertes vous préviennent quand quelque chose bouge dans une pièce où vous avez déjà laissé entrer quelqu'un.

Les règles sont évaluées à mesure que les rapports arrivent, et les navigateurs les envoient peu après le chargement de la page. En pratique, vous êtes prévenu d'un nouveau script dès la prochaine page vue qui le charge, pas lors d'un balayage nocturne. À titre de comparaison, Cloudflare Page Shield regroupe ses alertes de nouvelle ressource par jour et ses alertes de changement de code jusqu'à toutes les 24 heures.

C'est le mode d'échec habituel, et il vient du fait d'alerter sur des rapports bruts. Les vôtres arrivent dédupliqués, regroupés par directive et par origine, et les faux positifs d'extensions de navigateur sont déjà signalés. Vous pouvez aussi limiter chaque règle aux pages qui comptent : le checkout et le blog ne partagent jamais la même règle. Par-dessus tout cela, chaque règle accepte une temporisation : indiquez combien de temps elle doit rester silencieuse après s'être déclenchée, et un mauvais déploiement produit un message, pas quatre cents.

L'envoi est réessayé, et chaque tentative est enregistrée dans l'historique des envois avec son canal, son statut et la raison de l'échec. Les échecs transitoires, comme un timeout ou une erreur 5xx de votre endpoint, sont réessayés. Les échecs permanents ne le sont pas : une URL de webhook révoquée, un canal Slack qui n'existe plus ou une erreur 4xx indiquant que la requête elle-même est mauvaise ne passeront pas à la seconde tentative, et l'historique les affiche comme échoués plutôt que de réessayer indéfiniment. Vous lisez le résultat par règle et par canal, au lieu de deviner si un message est parti.

C'est la moitié détection et alerte de l'exigence. La 11.6.1 demande un mécanisme de détection des changements et des altérations qui alerte le personnel en cas de modification non autorisée des pages de paiement et de leurs en-têtes HTTP, telles que reçues par le navigateur du consommateur, au moins tous les sept jours. Les rapports CentralCSP viennent du navigateur du consommateur et ses règles se déclenchent à leur arrivée. Associez-la à l'inventaire de scripts pour la 6.4.3 et exportez les deux comme preuves.

Non. Les alertes s'appuient sur le même en-tête de réponse que la surveillance. Les navigateurs génèrent eux-mêmes les rapports : rien à installer, rien à maintenir à jour, et aucun script tiers ajouté aux pages que vous cherchez justement à protéger.

Oui, et c'est en général là qu'elles sont le plus utiles. Les règles s'appuient sur les rapports envoyés par le navigateur, pas sur les blocages qu'il effectue, et Content-Security-Policy-Report-Only envoie exactement les mêmes rapports de violation sans rien bloquer. Vous pouvez donc surveiller une nouvelle origine ou un script modifié pendant toute la phase report-only, avant d'appliquer quoi que ce soit.

Oui. Les règles sont une ressource REST, et les mêmes opérations sont disponibles via le serveur MCP intégré : intégrer cent sites devient une boucle plutôt qu'un après-midi. Une clé API agit au nom de la personne qui l'a créée, avec ses rôles, et la révoquer coupe l'intégration immédiatement.