Check des en-têtes de sécurité

Ce qu’il vérifie

Un monitor d’en-têtes de sécurité interroge l’URL avec un seul GET depuis chacune de ses régions, à son intervalle. Il suit les redirections et lit les noms des en-têtes de réponse. Le monitor signale les en-têtes sélectionnés qui sont présents et ceux qui manquent, sans jamais juger une valeur. En monitor à part avec son propre historique, il garde la posture des en-têtes d’un hôte visible indépendamment de sa disponibilité.

À utiliser quand

• Un autre monitor couvre déjà la disponibilité de l’endpoint, et seuls les en-têtes restent à surveiller.
• La posture des en-têtes demande son propre historique : son propre chiffre d’uptime, ses propres lignes de détail et son propre incident quand vous réglez la gravité sur failed.
• Un déploiement, un changement de CDN ou une mise à jour du reverse proxy peut retirer un en-tête sans prévenir. Vous voulez voir cette perte consignée dès le check suivant ou, avec la gravité réglée sur failed, dans un incident une fois le quorum atteint.

Il juge la présence, pas les valeurs : une Content-Security-Policy qui autorise tout passe donc. Pour des assertions sur le code de statut et le corps, utilisez le check HTTP(S), qui porte les mêmes 5 en-têtes en sous-check dans un seul monitor. Pour suivre le certificat comme signal à part, utilisez le check de certificat TLS.

Balayez horizontalement pour examiner la vue du produit.

app.perstat.io

Configuration

Cible. Une URL complète avec son schéma (https:// ou http://), selon la même règle que le check HTTP(S). La sonde résout et valide l’URL et chaque saut de redirection avant de l’appeler. Elle refuse les adresses de boucle locale, privées, link-local et de métadonnées cloud, si bien que le monitor ne peut pas viser un réseau interne.

Déroulement d’un check

1. Quand un check arrive à échéance, chaque région analyse l’URL et résout l’hôte par le résolveur du nœud. Elle confronte chaque adresse de la famille choisie aux plages bloquées. Chaque check expire après 10 s.
2. Chaque adresse reçoit un GET, avec la connexion épinglée à cette adresse. La sonde suit elle-même les redirections, 5 sauts au plus, et résout et valide à nouveau chaque saut avant de l’appeler.
3. Après la dernière redirection, la sonde relève les noms des en-têtes de réponse en minuscules. Elle ne lit pas les valeurs.
4. La sonde compare la sélection à la liste des 5 en-têtes recommandés et détermine ceux qui manquent. Le réglage missing_severity décide si un en-tête manquant vaut dégradé ou en échec.
5. Sur une URL https, la sonde lit une fois le certificat pour l’affichage. Le certificat ne change jamais le verdict.
6. La région envoie son résultat au plan de contrôle. La politique d’alerte décide si un résultat en échec ouvre un incident une fois le quorum atteint. Un résultat dégradé reste hors de l’évaluation des incidents.

Balayez horizontalement pour examiner la vue du produit.

app.perstat.io

Ce que contient un résultat

Code de statut

Le code de statut de la réponse après les redirections.

Temps de réponse

Le temps jusqu’à la réponse, par région et par adresse.

Ligne de détail

Une ligne qui indique que tous les en-têtes vérifiés étaient présents, ou qui nomme ceux qui manquent par leur libellé court, par exemple HSTS et CSP.

Couche de cause

Indique si un échec relevait du DNS de la cible (nom introuvable) ou, après une résolution réussie, de la cible elle-même. Toute autre cause est signalée comme inconnue.

Certificat

Sur une URL https, pour l’affichage seulement : le common name et les noms alternatifs, l’émetteur, les dates de validité et le statut de confiance.

Région, famille, adresse

Chaque résultat porte la région qui l’a mesuré, et un sous-résultat par famille IP et par adresse.

États et gravité

• okChaque en-tête sélectionné est présent dans la réponse après les redirections.
• dégradéAu moins un en-tête sélectionné manque à la gravité par défaut, ou une famille IP échoue pendant que l’autre répond.
• en panneUn en-tête sélectionné manque alors que missing_severity vaut failed. Une requête en échec compte aussi : erreur de résolution, cible bloquée, erreur de transport ou délai dépassé.
• erreurLa sélection d’en-têtes ne contient aucun nom valide. Cet état compte comme une panne de gravité critique.

Confirmé par quorum : par défaut, 2 régions doivent signaler l’échec avant l’ouverture d’un incident. La règle par défaut de l’organisation exige 2 régions et 2 checks consécutifs. Un monitor peut porter sa propre règle, avec un nombre ou un pourcentage, des checks consécutifs et une durée minimale.

Offres et limites

Intervalle minimal

300 s en Free, 60 s en Pulse, 30 s en Sentinel, 15 s en Command et 10 s en Enterprise. Le formulaire web propose 30 s, 1 min, 5 min, 15 min et 1 h. Les intervalles de 15 s et 10 s ne sont accessibles que par MCP.

Régions

2 sur 6 en Free, 3 sur 6 en Pulse et les 6 à partir de Sentinel.

Monitors

10 monitors de sonde en Free, 50 en Pulse, 150 en Sentinel, 500 en Command et un quota sur mesure en Enterprise. Onze types de checks régionaux partagent ce quota, tandis que les agents hôtes et les heartbeats ont le leur. Un pack de 50 monitors supplémentaires coûte 39 €.

Comparer toutes les limites

Depuis le pipeline ou un agent

La même config fonctionne dans l’étape de déploiement, dans un client MCP comme Claude Code et dans le formulaire ci-dessus. create_monitor exige une clé API valable pour toute l’organisation. Si vous omettez regions, l’offre applique sa valeur par défaut.

{
  "name": "Web security headers",
  "type": "http_headers",
  "interval_seconds": 300,
  "config": {
    "url": "https://www.example.com",
    "headers": [
      "strict-transport-security",
      "content-security-policy",
      "x-content-type-options"
    ],
    "missing_severity": "degraded"
  }
}

Chaque interface, avec sa limite

Limites

• Le check ne lit jamais la valeur d’un en-tête : une politique faible passe donc tant que l’en-tête est défini.
• Seuls les 5 en-têtes listés peuvent être sélectionnés. Une sélection sans nom valide termine le check en erreur.
• Le check juge la réponse après la dernière redirection, pas la première réponse. Un en-tête présent seulement sur la réponse de redirection n’est pas vu.
• La sonde envoie un GET par adresse, sans choix de méthode ni en-têtes de requête personnalisés.
• La sonde refuse les cibles sur des adresses privées, de boucle locale, link-local et de métadonnées cloud.
• Toutes les régions ne sondent pas en IPv6 : choisir ipv6 restreint donc les régions utilisables.

Types de checks liés

• Check HTTP(S)Disponibilité et réponse d’une URL, avec des assertions sur le statut, le corps et TLS.
• Check de certificat TLSExpiration, émetteur et sujet d’un certificat par handshake TLS direct, avec un avertissement avant l’expiration.
• Check d’hygiène DNSSPF, DMARC avec sa politique et CAA d’un domaine, notés comme posture et jamais comme panne.

Tous les types de checks