Check de cabeceras de seguridad

Qué verifica

Un monitor de cabeceras de seguridad pide la URL con un GET desde cada una de sus regiones en su intervalo. Sigue las redirecciones y lee los nombres de las cabeceras de respuesta. El monitor informa de qué cabeceras seleccionadas están presentes y cuáles faltan, y nunca evalúa un valor. Como monitor propio con historial propio, mantiene visible la postura de cabeceras de un host aparte de su disponibilidad.

Úsalo cuando

• Otro monitor ya cubre la disponibilidad del endpoint y solo hay que vigilar las cabeceras.
• La postura de cabeceras necesita registro propio: su propia cifra de uptime, sus propias líneas de detalle y su propio incidente cuando fijas la gravedad en failed.
• Un despliegue, un cambio en la CDN o una actualización del proxy inverso pueden retirar una cabecera sin aviso. Quieres ver la pérdida en el registro tras el siguiente check o, con la gravedad en failed, en un incidente cuando el quórum lo confirme.

Juzga la presencia, no los valores, así que una Content-Security-Policy que lo permite todo pasa. Para aserciones sobre código de estado y cuerpo, usa el check HTTP(S), que lleva las mismas 5 cabeceras como subcheck en un solo monitor. Para el certificado como señal propia, usa el check de certificado TLS.

Desliza lateralmente para ver la vista del producto.

app.perstat.io

Configuración

Objetivo. Una URL completa con esquema (https:// o http://), la misma regla que en el check HTTP(S). La sonda resuelve y valida la URL y cada salto de redirección antes de pedirlos. Rechaza las direcciones de loopback, privadas, link-local y de metadatos de nube, así que el monitor no puede apuntar a una red interna.

Cómo se ejecuta un check

1. Cuando toca un check, cada región analiza la URL y resuelve el host con el resolver propio del nodo. Valida cada dirección de la familia seleccionada contra los rangos bloqueados. Cada check expira a los 10 s.
2. Cada dirección recibe un GET, con la conexión fijada a esa dirección. La propia sonda sigue las redirecciones, como máximo 5 saltos, y resuelve y valida de nuevo cada salto antes de pedirlo.
3. Tras la última redirección, la sonda recoge en minúsculas los nombres de las cabeceras de respuesta. No lee los valores.
4. La sonda compara la selección con la lista de 5 cabeceras recomendadas y determina las ausentes. El ajuste missing_severity decide si una cabecera ausente significa degraded o failed.
5. En una URL https, la sonda lee el certificado una vez para mostrarlo. El certificado nunca cambia el veredicto.
6. La región envía su resultado al control plane. La política de alertas decide si un resultado fallido abre un incidente cuando el quórum lo confirma. Un resultado degradado queda fuera de la evaluación de incidentes.

Desliza lateralmente para ver la vista del producto.

app.perstat.io

Qué contiene un resultado

Código de estado

El código de estado de la respuesta tras las redirecciones.

Tiempo de respuesta

Tiempo hasta la respuesta, por región y por dirección.

Línea de detalle

Una línea que dice que todas las cabeceras comprobadas estaban presentes, o nombra las ausentes por su etiqueta corta, por ejemplo HSTS y CSP.

Capa de causa

Si el fallo está en el DNS del objetivo (nombre no encontrado) o, tras una resolución correcta, en el propio objetivo. Cualquier otra causa se registra como unknown.

Certificado

En una URL https, solo para mostrarlo: nombre común y nombres alternativos, emisor, fechas de validez y estado de confianza.

Región, familia, dirección

Cada resultado lleva la región que lo midió, y un subresultado por familia IP y por dirección.

Estados y gravedad

• okTodas las cabeceras seleccionadas están presentes en la respuesta tras las redirecciones.
• degradadoFalta al menos una cabecera seleccionada con la gravedad por defecto, o falla una familia IP mientras la otra responde.
• caídoFalta una cabecera seleccionada con missing_severity en failed. También cuenta una petición fallida: un error de resolución, un objetivo bloqueado, un error de transporte o un timeout.
• errorLa selección de cabeceras no contiene ningún nombre válido. Cuenta como caída con gravedad critical.

Confirmado por quórum: por defecto, 2 regiones deben informar del fallo antes de que se abra un incidente. El valor por defecto de la organización pide 2 regiones y 2 checks consecutivos. Un monitor puede llevar su propia regla con número o porcentaje, checks consecutivos y una duración mínima.

Planes y límites

Intervalo mínimo

300 s en Free, 60 s en Pulse, 30 s en Sentinel, 15 s en Command y 10 s en Enterprise. El formulario web ofrece 30 s, 1 min, 5 min, 15 min y 1 h. Los mínimos de 15 s y 10 s solo se alcanzan por MCP.

Regiones

2 de 6 en Free, 3 de 6 en Pulse y las 6 desde Sentinel.

Monitores

10 monitores de sonda en Free, 50 en Pulse, 150 en Sentinel, 500 en Command y un cupo a medida en Enterprise. Once tipos de check regionales comparten este cupo, mientras que los agentes de host y los heartbeats tienen la suya. Un paquete de 50 monitores más cuesta 39 €.

Comparar todos los límites

Desde la pipeline o un agente

La misma config sirve en el paso de despliegue, en un cliente MCP como Claude Code y en el formulario de arriba. create_monitor necesita una clave de API válida para toda la organización. Si omites regions, el plan aplica su valor por defecto.

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

Cada interfaz, con su límite

Límites

• El check nunca lee el valor de una cabecera, así que una política débil pasa mientras la cabecera esté definida.
• Solo se pueden seleccionar las 5 cabeceras listadas. Una selección sin ningún nombre válido termina el check como error.
• El check evalúa la respuesta posterior a la última redirección, no la primera respuesta. No ve una cabecera definida solo en la respuesta que redirige.
• La sonda envía un GET por dirección, sin elección de método y sin cabeceras de petición propias.
• La sonda rechaza los objetivos en direcciones privadas, de loopback, link-local y de metadatos de nube.
• No todas las regiones sondean IPv6, así que seleccionar ipv6 restringe las regiones utilizables.

Tipos de check relacionados

• Check HTTP(S)Disponibilidad y respuesta de una URL, con aserciones sobre estado, cuerpo y TLS.
• Check de certificado TLSCaducidad, emisor y sujeto de un certificado por handshake TLS directo, con un aviso antes de la caducidad.
• Check de higiene DNSSPF, DMARC con su política y CAA de un dominio, calificados como postura y nunca como caída.

Todos los tipos de check