--- title: "Alertes de violations CSP dans Slack et Teams" description: "Alertes CSP dans Slack, Teams, Google Chat, Telegram, e-mail ou webhook dès qu'une nouvelle origine, un script modifié ou un pic de violations apparaît." url: "https://next.centralcsp.com/fr/platform/alerting/" lang: "fr" --- Alertes # Votre site a changé. Votre équipe le sait déjà. Ajoutez une règle une fois. Quand le navigateur d'un vrai visiteur signale le changement, le message est déjà dans le canal responsable de cette page. [Démarrer l'essai gratuit](https://app.next.centralcsp.com) [Voir ce que nous surveillons](https://next.centralcsp.com/fr/platform/monitoring/) - Se déclenche à l'arrivée Pas un balayage nocturne - Six destinations Chat, e-mail ou webhook - Routage par site Et par équipe - Aucun agent Un en-tête de réponse Déclencheurs ## Ce qui mérite de déranger quelqu'un. Six choses qu'une règle peut surveiller, sur la page de votre choix. - ### Une nouvelle origine apparaît Un script chargé depuis un hôte jamais vu. La plupart des attaques côté client commencent exactement là. - ### Un script a changé Un fichier que vous exécutez ne correspond plus au hash d'hier. Votre build l'a fait, ou quelqu'un d'autre. - ### Quelque chose a touché une page de paiement Les pages de données de carte ont leurs propres règles, car la norme PCI DSS 11.6.1 impose d'alerter sur leurs changements. - ### Une CVE connue apparaît Une bibliothèque que vous chargez fait l'objet d'un avis publié. Vous l'apprenez avec la version et l'identifiant CVE. - ### Les rapports s'envolent Les violations ont bondi après le déploiement de 16 h. Quelque chose a cassé à grande échelle, et les navigateurs l'ont dit en premier. - ### Un signal silencieux se réveille Une directive muette tout le trimestre se met à parler. À regarder avant que cela ne devienne un incident. Canaux ## Voilà à quoi ressemble une alerte. La même règle, qui atteint trois équipes là où elles travaillent déjà. Chaque règle choisit sa destination : un incident sur le checkout et une alerte du site vitrine n'atterrissent jamais dans le même fil. - - - Toutes les destinations qu'une règle peut atteindre - Slack - Microsoft Teams - Google Chat - Telegram - E-mail - Webhooks FAQ ## Questions fréquentes Canaux, rapidité, bruit et conformité : les réponses. ### Puis-je recevoir les alertes de violation CSP dans Slack ? 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. ### Pourquoi alerter plutôt que simplement bloquer le script ? 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. ### En combien de temps une alerte arrive-t-elle ? 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. ### Ne vais-je pas être noyé sous le bruit CSP ? 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. ### Cela répond-il à l'exigence PCI DSS 11.6.1 ? 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. ### Faut-il un agent ou un script sur la page ? 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. ### Puis-je créer des règles d'alerte via l'API ? Oui. Les règles sont une ressource REST avec des jetons à portée limitée, 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. ## Créez une règle aujourd'hui. Oubliez-la jusqu'à ce qu'elle compte. Ajoutez l'en-tête, connectez un canal, choisissez le changement qui mérite un message. 14 jours d'essai gratuit, aucun agent à déployer. [Démarrer l'essai gratuit](https://app.next.centralcsp.com) [Vérifiez votre configuration de reporting](https://next.centralcsp.com/fr/tools/reporting-api/) --- Disponible en : [en](https://next.centralcsp.com/en/platform/alerting/), [fr](https://next.centralcsp.com/fr/platform/alerting/)