Security-Header-Check

Was er prüft

Ein Security-Header-Monitor ruft die URL in seinem Intervall aus jeder seiner Regionen mit einem GET ab. Er folgt Weiterleitungen und liest die Namen der Antwort-Header. Der Monitor meldet, welche der gewählten Header vorhanden sind und welche fehlen, und bewertet nie einen Wert. Als eigener Monitor mit eigener Historie hält er den Header-Stand eines Hosts getrennt von seiner Verfügbarkeit sichtbar.

Wann Sie ihn einsetzen

• Ein anderer Monitor deckt die Verfügbarkeit des Endpunkts schon ab, und Sie wollen nur die Header beobachten.
• Der Header-Stand braucht eine eigene Aufzeichnung: eine eigene Uptime-Zahl, eigene Detailzeilen und einen eigenen Incident, wenn Sie die Schwere auf failed setzen.
• Ein Deploy, eine CDN-Änderung oder ein Update des Reverse Proxy kann einen Header unbemerkt entfernen. Sie wollen den Verlust nach dem nächsten Check in der Aufzeichnung sehen oder, bei Schwere failed, in einem Incident, sobald das Quorum einig ist.

Er bewertet das Vorhandensein, nicht die Werte, deshalb besteht auch eine Content-Security-Policy, die alles erlaubt. Für Bedingungen an Statuscode und Body nutzen Sie den HTTP(S)-Check, der dieselben 5 Header als Subcheck im selben Monitor mitführt. Für das Zertifikat als eigenes Signal nutzen Sie den TLS-Zertifikat-Check.

Seitlich wischen, um die Produktansicht anzusehen.

app.perstat.io

Konfiguration

Ziel. Eine vollständige URL mit Schema (https:// oder http://), dieselbe Regel wie beim HTTP(S)-Check. Der Prüfpunkt löst die URL und jeden Weiterleitungssprung vor dem Abruf auf und prüft sie. Loopback-, private, Link-local- und Cloud-Metadaten-Adressen weist er ab, deshalb lässt sich der Monitor nicht auf ein internes Netz richten.

So läuft ein Check ab

1. Ist ein Check fällig, parst jede Region die URL und löst den Host über den eigenen Resolver des Knotens auf. Sie prüft jede Adresse der gewählten Familie gegen die gesperrten Bereiche. Jeder Check läuft nach 10 s in den Timeout.
2. Jede Adresse erhält ein GET, dessen Verbindung fest an diese Adresse gebunden ist. Der Prüfpunkt folgt Weiterleitungen selbst, höchstens 5 Sprünge, und löst jeden Sprung vor dem Abruf erneut auf und prüft ihn.
3. Nach der letzten Weiterleitung sammelt der Prüfpunkt die Namen der Antwort-Header in Kleinschreibung. Die Werte liest er nicht.
4. Der Prüfpunkt gleicht die Auswahl mit der Liste der 5 empfohlenen Header ab und bestimmt die fehlenden. Die Einstellung missing_severity entscheidet, ob ein fehlender Header eingeschränkt oder ausgefallen bedeutet.
5. Bei einer https-URL liest der Prüfpunkt das Zertifikat einmal zur Anzeige. Das Zertifikat ändert das Urteil nie.
6. Die Region sendet ihr Ergebnis an die Control Plane. Die Alarmregel entscheidet, ob ein fehlgeschlagenes Ergebnis einen Incident öffnet, sobald das Quorum einig ist. Ein eingeschränktes Ergebnis bleibt aus der Incident-Bewertung heraus.

Seitlich wischen, um die Produktansicht anzusehen.

app.perstat.io

Was ein Ergebnis enthält

Statuscode

Der Statuscode der Antwort nach den Weiterleitungen.

Antwortzeit

Zeit bis zur Antwort, je Region und je Adresse.

Detailzeile

Eine Zeile, die sagt, dass alle geprüften Header vorhanden waren, oder die fehlenden mit ihren Kurzformen nennt, zum Beispiel HSTS und CSP.

Ursachenschicht

Ob ein Fehler beim DNS des Ziels lag (Name nicht gefunden) oder, nach erfolgreicher Auflösung, beim Ziel selbst. Jede andere Ursache meldet Perstat als unbekannt.

Zertifikat

Bei einer https-URL, nur zur Anzeige: Common Name und alternative Namen, Aussteller, Gültigkeitsdaten und Vertrauensstatus.

Region, Familie, Adresse

Jedes Ergebnis trägt die Region, die es gemessen hat, und ein Teilergebnis je IP-Familie und je Adresse.

Zustände und Schwere

• okJeder gewählte Header ist in der Antwort nach den Weiterleitungen vorhanden.
• eingeschränktMindestens ein gewählter Header fehlt bei der voreingestellten Schwere, oder eine IP-Familie fällt aus, während die andere antwortet.
• ausgefallenEin gewählter Header fehlt, und missing_severity steht auf failed. Eine fehlgeschlagene Anfrage zählt ebenfalls: ein Auflösungsfehler, ein gesperrtes Ziel, ein Transportfehler oder ein Timeout.
• FehlerDie Header-Auswahl enthält keinen gültigen Namen. Das zählt als Ausfall mit Schwere critical.

Per Quorum bestätigt: Standardmäßig müssen 2 Regionen den Fehler melden, bevor Perstat einen Incident öffnet. Die Voreinstellung der Organisation verlangt 2 Regionen und 2 aufeinanderfolgende Checks. Ein Monitor kann eine eigene Regel tragen, mit Anzahl oder Prozent, aufeinanderfolgenden Checks und einer Mindestdauer.

Tarife und Grenzen

Kürzestes Intervall

300 s in Free, 60 s in Pulse, 30 s in Sentinel, 15 s in Command und 10 s in Enterprise. Das Webformular bietet 30 s, 1 min, 5 min, 15 min und 1 h. Die Untergrenzen von 15 s und 10 s erreichen Sie nur über MCP.

Regionen

2 von 6 in Free, 3 von 6 in Pulse und alle 6 ab Sentinel.

Monitore

10 regionale Monitore in Free, 50 in Pulse, 150 in Sentinel, 500 in Command und ein individuelles Kontingent in Enterprise. Die elf regionalen Checktypen teilen sich dieses Kontingent, Host-Agenten und Heartbeats haben ein eigenes. Ein Paket mit 50 weiteren Monitoren kostet 39 €.

Alle Tarifgrenzen vergleichen

Aus der Pipeline oder von einem Agenten

Dieselbe config gilt im Deploy-Schritt, in einem MCP-Client wie Claude Code und im Formular oben. create_monitor braucht einen API-Schlüssel für die ganze Organisation. Wenn Sie regions weglassen, wählt der Tarif seine Voreinstellung.

{
  "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"
  }
}

Jede Schnittstelle mit ihrer Grenze

Grenzen

• Der Check liest nie den Wert eines Headers, deshalb besteht auch eine schwache Policy, solange der Header gesetzt ist.
• Nur die 5 gelisteten Header sind wählbar. Eine Auswahl ohne gültigen Namen beendet den Check als Fehler.
• Der Check bewertet die Antwort nach der letzten Weiterleitung, nicht die erste Antwort. Einen Header, der nur auf der weiterleitenden Antwort steht, sieht er nicht.
• Der Prüfpunkt sendet ein GET je Adresse, ohne Methodenwahl und ohne eigene Anfrage-Header.
• Der Prüfpunkt weist Ziele auf privaten, Loopback-, Link-local- und Cloud-Metadaten-Adressen ab.
• Nicht jede Region prüft IPv6, deshalb schränkt die Auswahl von ipv6 die nutzbaren Regionen ein.

Verwandte Checktypen

• HTTP(S)-CheckVerfügbarkeit und Antwort einer URL, mit Bedingungen an Status, Body und TLS.
• TLS-Zertifikat-CheckAblauf, Aussteller und Subject eines Zertifikats per direktem TLS-Handshake, mit Hinweis vor dem Ablauf.
• DNS-Hygiene-CheckSPF, DMARC mit Policy und CAA einer Domain, bewertet als Konfigurationsstand und nie als Ausfall.

Alle Checktypen