Check degli header di sicurezza

Cosa verifica

Un monitor degli header di sicurezza richiede l’URL con una sola GET da ciascuna delle sue regioni, al suo intervallo. Segue i redirect e legge i nomi degli header di risposta. Il monitor riporta quali header selezionati sono presenti e quali mancano, e non giudica mai un valore. Come monitor a sé con la propria cronologia, mostra la postura degli header di un host separata dalla sua disponibilità.

Da usare quando

• Un altro monitor copre già la disponibilità dell’endpoint e vanno osservati solo gli header.
• La postura degli header richiede un registro proprio: la propria cifra di uptime, le proprie righe di dettaglio e il proprio incident quando imposti la gravità a failed.
• Un deploy, un cambio di CDN o un aggiornamento del reverse proxy può far sparire un header senza preavviso. Vuoi vedere la perdita nel registro dopo il check successivo oppure, con la gravità impostata a failed, in un incident una volta raggiunto il quorum.

Giudica la presenza, non i valori, quindi una Content-Security-Policy che permette tutto passa. Per asserzioni su codice di stato e body usa il check HTTP(S), che porta gli stessi 5 header come subcheck in un solo monitor. Per il certificato come segnale a sé usa il check del certificato TLS.

Scorri di lato per esaminare la vista del prodotto.

app.perstat.io

Configurazione

Target. Un URL completo di schema (https:// o http://), la stessa regola del check HTTP(S). Prima della richiesta la sonda risolve e valida l’URL e ogni salto di redirect. Rifiuta gli indirizzi loopback, privati, link-local e di metadata cloud, così il monitor non può essere puntato verso una rete interna.

Come si svolge un check

1. Quando scatta un check, ogni regione analizza l’URL e risolve l’host tramite il resolver del proprio nodo. Valida ogni indirizzo della famiglia selezionata contro gli intervalli bloccati. Ogni check va in timeout dopo 10 s.
2. Ogni indirizzo riceve una GET, con la connessione fissata a quell’indirizzo. La sonda segue i redirect da sé, al massimo 5 salti, e risolve e valida di nuovo ogni salto prima di richiederlo.
3. Dopo l’ultimo redirect, la sonda raccoglie i nomi degli header di risposta in minuscolo. Non legge i valori.
4. La sonda confronta la selezione con la lista dei 5 header raccomandati e determina quelli mancanti. L’impostazione missing_severity decide se un header mancante significa degraded o failed.
5. Su un URL https, la sonda legge il certificato una volta a scopo di visualizzazione. Il certificato non cambia mai il verdetto.
6. La regione invia il suo risultato al control plane. La regola di alert decide se un risultato fallito apre un incident una volta raggiunto il quorum. Un risultato degradato resta fuori dalla valutazione degli incident.

Scorri di lato per esaminare la vista del prodotto.

app.perstat.io

Cosa contiene un risultato

Codice di stato

Il codice di stato della risposta dopo i redirect.

Tempo di risposta

Tempo fino alla risposta, per regione e per indirizzo.

Riga di dettaglio

Una riga che dice che tutti gli header controllati erano presenti, oppure nomina quelli mancanti con le loro sigle, per esempio HSTS e CSP.

Livello della causa

Se un fallimento è imputabile al DNS del target (nome non trovato) oppure, dopo un lookup riuscito, al target stesso. Ogni altra causa viene riportata come unknown.

Certificato

Su un URL https, solo a scopo di visualizzazione: common name e nomi alternativi, emittente, date di validità e stato di fiducia.

Regione, famiglia, indirizzo

Ogni risultato porta la regione che l’ha misurato, e un sotto-risultato per famiglia IP e per indirizzo.

Stati e gravità

• okOgni header selezionato è presente nella risposta dopo i redirect.
• degradatoAlmeno un header selezionato manca con la gravità predefinita, oppure una famiglia IP fallisce mentre l’altra risponde.
• downUn header selezionato manca con missing_severity impostato a failed. Conta anche una richiesta fallita: un errore di risoluzione, un target bloccato, un errore di trasporto o un timeout.
• erroreLa selezione degli header non contiene nessun nome valido. Conta come disservizio con gravità critica.

Confermato dal quorum: di default, 2 regioni devono segnalare il guasto prima che si apra un incident. Il default dell’organizzazione richiede 2 regioni e 2 check consecutivi. Un monitor può avere una regola propria con numero o percentuale, check consecutivi e una durata minima.

Piani e limiti

Intervallo minimo

300 s in Free, 60 s in Pulse, 30 s in Sentinel, 15 s in Command e 10 s in Enterprise. Il modulo web offre 30 s, 1 min, 5 min, 15 min e 1 h. I minimi di 15 s e 10 s si raggiungono solo tramite MCP.

Regioni

2 su 6 in Free, 3 su 6 in Pulse e tutte e 6 da Sentinel.

Monitor

10 monitor di sonda in Free, 50 in Pulse, 150 in Sentinel, 500 in Command e una quota su misura in Enterprise. Undici tipi di check regionali condividono questa quota, mentre host agent e heartbeat hanno la loro. Un pacchetto di 50 monitor in più costa 39 €.

Confronta tutti i limiti

Dalla pipeline o da un agente

La stessa config funziona nello step di deploy, in un client MCP come Claude Code e nel modulo qui sopra. create_monitor richiede una chiave API valida per tutta l’organizzazione. Se ometti regions, il piano sceglie il suo default.

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

Ogni interfaccia, con il suo limite

Limiti

• Il check non legge mai il valore di un header, quindi una policy debole passa finché l’header è impostato.
• Si possono selezionare solo i 5 header elencati. Una selezione senza un nome valido chiude il check come errore.
• Il check giudica la risposta dopo l’ultimo redirect, non la prima risposta. Un header impostato solo sulla risposta che reindirizza non viene visto.
• La sonda invia una GET per indirizzo, senza scelta del metodo e senza header di richiesta personalizzati.
• La sonda rifiuta i target su indirizzi privati, loopback, link-local e di metadata cloud.
• Non tutte le regioni sondano IPv6, quindi selezionare ipv6 restringe le regioni utilizzabili.

Tipi di check correlati

• Check HTTP(S)Disponibilità e risposta di un URL, con asserzioni su stato, body e TLS.
• Check del certificato TLSScadenza, emittente e soggetto di un certificato tramite handshake TLS diretto, con un avviso prima della scadenza.
• Check di igiene DNSSPF, DMARC con la sua policy e CAA di un dominio, valutati come postura e mai come disservizio.

Tutti i tipi di check