Respuesta a una solicitud HTTP

En el capítulo anterior vimos la primera parte de Respuesta a una solicitud HTTP y Códigos de estado HTTP, en este capítulo aprenderás cómo se compone una respuesta HTTP y cómo analizar cada uno de sus encabezados (headers), algo esencial para cualquier profesional de la ciberseguridad o pentester. Verás en detalle cómo el servidor devuelve el resultado de una solicitud, qué información contienen los encabezados como Date, Cache-Control, ETag, Content-Type, Content-Encoding, Server, Set-Cookie, Location y los encabezados de seguridad (CSP, HSTS, X-Content-Type-Options, Referrer-Policy).

Comprender estos elementos te permitirá identificar configuraciones débiles, fugas de información, vulnerabilidades de sesión y errores de seguridad que los atacantes suelen explotar. Cada línea de la respuesta HTTP puede revelar pistas sobre la estructura interna de una aplicación o sobre mecanismos que, si están mal configurados, se convierten en puertas de entrada para ataques avanzados.

Table of Contents

La imagen representa de manera sencilla el momento en el que un servidor web envía una respuesta HTTP (HTTP Response) al navegador. Este flujo corresponde a la segunda parte de la comunicación entre cliente y servidor: después de que el navegador envía una petición (HTTP Request), el servidor procesa la solicitud, genera la respuesta correspondiente y la devuelve al cliente.

Ejemplo de respuesta:

HTTP/1.1 200 OK
Server: nginx/1.15.8

Date: Fri, 17 feb 2025 16:32:04 GMT
Content-Type: text/html
Content-Length: 98

<html>
<head>
	<title>Laprovittera Carlos</title>
</head>
<body>
	 Welcome To laprovittera.com
</body>
</html>

Para desglosar cada línea de la respuesta:

Línea 1: HTTP 1.1 es la versión del protocolo HTTP que utiliza el servidor y luego sigue el código de estado HTTP en este caso «200 OK» que nos indica que la solicitud se ha completado correctamente.

Línea 2: Esto nos indica el software del servidor web y el número de versión.

Línea 3: La fecha, hora y zona horaria actuales del servidor web.

Línea 4: El encabezado Content-Type le dice al cliente qué tipo de información se enviará, como HTML, imágenes, videos, PDF, XML .

Línea 5: Content-Length le dice al cliente qué tan larga es la respuesta, de esta manera podemos confirmar que no faltan datos.

Línea 6: La respuesta HTTP contiene una línea en blanco para confirmar el final de la respuesta HTTP .

Líneas 7-14: La información que se ha solicitado, en este caso la página de inicio.

Ahora que sabemos qué comprende una solicitud HTTP, inspeccionemos las respuestas HTTP. En respuesta a la solicitud HTTP, el servidor web responderá con el recurso solicitado, precedido por una serie de nuevos encabezados de respuesta HTTP. Su navegador web utilizará estos nuevos encabezados de respuesta del servidor web para interpretar el contenido del cuerpo de la respuesta.

Línea de estado de respuesta HTTP

La primera línea de una respuesta HTTP es la línea de estado, que consta de la versión del protocolo (HTTP 1.1) seguida del código de estado HTTP (200) y su significado textual relativo (OK). La imagen enseña la anatomía de una respuesta HTTP y sirve como mapa para auditar comportamientos y malas configuraciones: entender qué significa cada encabezado y cómo influye en la seguridad y operativa es una habilidad básica y muy práctica para cualquier pentester web.

La status-line es siempre el punto de partida de una respuesta HTTP. Los códigos de estado permiten al cliente interpretar el resultado de la petición y se agrupan en distintas categorías:

1xx (Informativos): indican que la solicitud se está procesando.
2xx (Éxito): la acción se completó correctamente (200 OK, 201 Created, etc.).
3xx (Redirección): el cliente debe realizar otra acción, como seguir una URL diferente (301 Moved Permanently, 302 Found).
4xx (Error del cliente): la solicitud contiene errores o el recurso no está disponible (400 Bad Request, 403 Forbidden, 404 Not Found).
5xx (Error del servidor): algo falló en el lado del servidor (500 Internal Server Error, 502 Bad Gateway, etc.).

Después de la status-line, la imagen muestra los encabezados (headers) de la respuesta: Date, Cache-Control, Content-Type, Content-Encoding, Server y Content-Length. Estos definen información adicional sobre la respuesta, como la fecha de emisión, políticas de caché, tipo de contenido y tecnología del servidor. Finalmente, la parte inferior (<PAGE CONTENT>) representa el cuerpo (body), que contiene el contenido real enviado al navegador.

Todo esto ya lo vimos en el capítulo anterior, ahora vamos a ver en profundidad el encabezado de respuesta.

Encabezado de fecha de respuesta HTTP

El encabezado «Fecha» en una respuesta HTTP se utiliza para indicar la fecha y la hora en que el servidor generó la respuesta.
Ayuda a los clientes e intermediarios a comprender la actualidad de la respuesta y a sincronizar la hora entre el servidor y el cliente
Ejemplo: Date: Fri, 23 Aug 2024 10:43:21 GMT – este encabezado muestra la fecha y hora exactas en que el servidor generó la respuesta.

La imagen muestra una respuesta HTTP en la que se resalta el encabezado Date, que indica la fecha y hora exactas en las que el servidor generó la respuesta:

Date: Fri, 13 Mar 2015 11:26:05 GMT.

Este campo forma parte de los encabezados generales de HTTP y está presente en casi todas las respuestas del servidor. Su formato está definido por el estándar RFC 7231, utilizando siempre la zona horaria GMT (Greenwich Mean Time) para mantener la coherencia entre sistemas distribuidos. La cabecera Date permite al cliente (por ejemplo, el navegador o un proxy) conocer el momento preciso en que el contenido fue emitido, lo que es útil para sincronizar tiempos de caché, validar recursos o calcular la edad de una respuesta mediante encabezados como Age o Cache-Control.

En el contexto del pentesting y la seguridad web, este encabezado, aunque aparentemente inofensivo, puede aportar información interesante. Si el valor de Date difiere notablemente de la hora real o entre distintas peticiones, podría indicar desincronización en los servidores, algo que a veces se explota en ataques relacionados con sesiones o tokens dependientes del tiempo. Además, diferencias en los formatos o en los segundos precisos pueden delatar el uso de distintos servidores backend, ayudando en el fingerprinting de la infraestructura.

También es importante notar que algunos servidores intermedios (como CDNs o balanceadores de carga) pueden modificar o regenerar este encabezado, por lo que, al observarlo en detalle junto con otros como Via, Age o Server, se puede identificar si la respuesta fue entregada directamente desde el servidor de origen o desde un intermediario en caché.

En resumen, el encabezado Date cumple una función esencial en la gestión temporal de las respuestas HTTP, permitiendo sincronización y control de caché, pero también puede servir como pista técnica en auditorías de seguridad para entender la estructura y comportamiento temporal de los servidores que componen una aplicación web.

Encabezado de control de caché de respuesta HTTP

Los encabezados de caché permiten que el navegador y el servidor se pongan de acuerdo sobre las reglas de almacenamiento en caché. Permiten a los servidores web indicar a los clientes cuánto tiempo pueden almacenar en caché la respuesta y bajo qué condiciones deben revalidarla con el servidor. Esto ayuda a optimizar el rendimiento y la eficiencia de las aplicaciones web al reducir las solicitudes de red innecesarias.

Ejemplo: Cache-Control: max-age=600 – Este encabezado indica al cliente cuánto tiempo puede almacenar en caché la respuesta antes de volver a consultarla con el servidor. También puede evitar que se almacene en caché información confidencial si es necesario (usando no-cache).

La imagen muestra una respuesta HTTP en la que se resalta el encabezado Cache-Control, responsable de indicar cómo debe manejarse el almacenamiento en caché del recurso. En este caso, el valor Cache-Control: private, max-age=0 le indica al navegador que el contenido solo puede ser almacenado de forma privada (por ejemplo, en la caché local del usuario) y que además debe considerarse inmediatamente expirado (max-age=0), por lo que cada vez que se solicite, el cliente deberá verificar de nuevo con el servidor si existe una versión actualizada.

Valores de Cache-Control

Este encabezado forma parte de las políticas de control de caché de HTTP/1.1, y permite especificar cómo deben comportarse tanto los navegadores como los proxies intermedios. Algunos de los valores más comunes incluyen:

public: el recurso puede ser almacenado por cualquier caché (incluidos proxies compartidos). Indica que la respuesta puede ser almacenada en caché por cualquier caché intermedia (como servidores proxy) y compartida entre diferentes usuarios.
private: el recurso solo debe ser almacenado por el navegador del usuario. Especifica que la respuesta está destinada a un usuario específico y no debe ser almacenada en caché por cachés intermedias.
no-cache: el cliente debe revalidar con el servidor antes de usar la versión almacenada. Indica al cliente que revalide la respuesta con el servidor antes de usar la versión almacenada en caché. No impide el almacenamiento en caché, pero requiere la revalidación.
no-store: prohíbe completamente almacenar el recurso (ideal para datos sensibles). Indica al cliente y a las cachés intermedias que no almacenen ninguna versión de la respuesta. Garantiza que la respuesta no se almacene en caché de ninguna forma.
max-age=<SEGUNDOS>: Especifica la cantidad máxima de tiempo en segundos que el cliente puede almacenar en caché la respuesta. Después de este período, el cliente debe revalidarla con el servidor

Desde el punto de vista del pentesting y la seguridad web, este encabezado tiene gran importancia. Una mala configuración de la caché puede provocar filtraciones de información sensible. Por ejemplo, si una respuesta con datos personales o de sesión se almacena en una caché pública (como un proxy o CDN), otros usuarios podrían acceder a ella. También es común que aplicaciones con autenticación no restrinjan la caché en las páginas privadas, lo que puede permitir recuperar información incluso después de cerrar sesión.

Durante una auditoría, los testers suelen revisar los encabezados Cache-Control, Pragma, Expires y ETag para verificar que los recursos sensibles no sean almacenados ni servidos desde cachés compartidas. En particular, configuraciones como Cache-Control: private, no-store o Cache-Control: no-store, must-revalidate son las recomendadas para proteger contenido dinámico o confidencial.

El encabezado Cache-Control define las reglas de almacenamiento y revalidación del contenido HTTP. En entornos seguros, su correcta implementación garantiza que los datos sensibles no queden expuestos, mientras que en el análisis de seguridad, una configuración inadecuada puede ser una pista clara de fuga de información o de mala gestión de sesiones.

ETag (Entity Tag)

La imagen explica de forma muy clara el funcionamiento del encabezado ETag (Entity Tag) en el protocolo HTTP, mostrando cómo ayuda a optimizar las cargas de páginas mediante la validación de caché. En el primer cuadro, el navegador realiza una petición inicial (GET cats.css) para descargar un archivo CSS. El servidor responde con un 200 OK e incluye el encabezado ETag: «ab23ef», que representa una especie de huella digital (hash) del contenido del archivo. El navegador guarda tanto el archivo como su ETag asociado.

En el segundo cuadro, al día siguiente, cuando el navegador vuelve a necesitar el mismo archivo (cats.css), no lo descarga directamente, sino que primero envía una petición condicional (GET cats.css con el encabezado If-None-Match: «ab23ef»). De esta manera le pregunta al servidor: “¿Ha cambiado el archivo desde la última vez?”. El servidor compara el ETag recibido con la versión actual del archivo y, si son iguales, responde con un 304 Not Modified, indicando que el contenido no ha cambiado. Así el navegador puede reutilizar el archivo almacenado localmente sin volver a descargarlo, haciendo que la página cargue más rápido.

Desde el punto de vista del pentesting y la seguridad, los ETags también pueden ser una fuente de información interesante. Aunque su propósito es mejorar el rendimiento, un ETag mal implementado puede filtrar detalles internos del sistema, como identificadores únicos de archivos, hashes predecibles o información de backend. Además, existen técnicas de seguimiento (tracking) que abusan del uso de ETags para identificar usuarios de forma persistente, incluso si borran cookies o cambian de sesión, ya que los ETags pueden ser reutilizados por el servidor como identificadores únicos.

Por otra parte, en auditorías de seguridad, analizar los ETags puede ayudar a determinar si una aplicación utiliza correctamente los mecanismos de caché o si podría estar exponiendo contenido sensible almacenado. En entornos seguros, es buena práctica configurar los ETags de manera aleatoria y evitar incluir en ellos información que permita deducir rutas, IDs o datos internos del servidor.

En resumen, la imagen muestra cómo el ETag actúa como un identificador de versión de un recurso, optimizando las peticiones HTTP al evitar descargas innecesarias. Pero, como ocurre con muchos mecanismos de eficiencia, también debe ser gestionado con cuidado para no convertirse en una fuente de exposición de información o de rastreo no deseado.

Encabezado de tipo de contenido de respuesta HTTP

El encabezado «Tipo de contenido» en una respuesta HTTP se utiliza para indicar el tipo de medio del contenido de la respuesta. Le indica al cliente qué tipo de datos está enviando el servidor para que el cliente pueda gestionarlos adecuadamente.

Ejemplo: Content-Type: text/html; charset=utf-8 – Indica al cliente el tipo de contenido que recibe, por ejemplo, si es HTML, JSON u otro. También incluye el conjunto de caracteres (como UTF-8) para que el navegador lo muestre correctamente.

La imagen muestra una respuesta HTTP en la que se resalta el encabezado Content-Type, un campo fundamental que indica al navegador o cliente cuál es el tipo de contenido que está recibiendo y cómo debe interpretarlo. En este caso, el valor es Content-Type: text/html; charset=UTF-8, lo que significa que el servidor está enviando un documento HTML codificado con el conjunto de caracteres UTF-8. El encabezado Content-Type se compone de dos partes:

El tipo MIME (Multipurpose Internet Mail Extensions), que define el formato general del contenido. Ejemplos comunes son text/html, application/json, image/png, o text/css.
El charset, que especifica la codificación de caracteres usada en el contenido textual (como UTF-8, ISO-8859-1, etc.).

Este encabezado es esencial para que el navegador renderice correctamente la información. Por ejemplo, si el contenido es una página HTML, el navegador la mostrará como una página web; pero si el Content-Type fuera application/json, el navegador sabría que se trata de una respuesta de datos estructurados, común en APIs.

Desde el punto de vista de la seguridad web y el pentesting, este encabezado es especialmente importante porque un valor incorrecto o mal configurado puede generar vulnerabilidades de tipo MIME sniffing o cross-site scripting (XSS). Si un servidor no especifica el tipo de contenido de forma explícita, el navegador podría intentar “adivinarlo” (sniffing) y llegar a interpretar archivos peligrosos como ejecutables o scripts. Por eso, se recomienda siempre definir correctamente el tipo de contenido y, además, incluir el encabezado X-Content-Type-Options: nosniff, para impedir que el navegador interprete tipos distintos a los declarados.

En pruebas de pentesting, observar el Content-Type ayuda a identificar cómo el servidor maneja los distintos formatos y si existen inconsistencias que podrían explotarse. Por ejemplo, respuestas con text/html cuando deberían ser application/json podrían permitir inyección de código si el contenido se renderiza en el navegador.

En resumen, el encabezado Content-Type no solo indica el formato del contenido enviado por el servidor, sino que también juega un papel crucial en la seguridad y correcta interpretación de las respuestas HTTP. En el ejemplo mostrado, el servidor está comunicando que la respuesta es una página HTML en formato UTF-8, lo cual es una configuración adecuada y segura para contenido web estándar.

Encabezado de codificación de contenido de respuesta HTTP

El encabezado «Codificación de contenido» en una respuesta HTTP se utiliza para especificar la codificación de compresión aplicada al contenido de la respuesta. Indica al cliente cómo el servidor ha codificado los datos de respuesta, lo que permite al cliente decodificar y descomprimir los datos correctamente

La imagen muestra una respuesta HTTP en la que se destaca el encabezado Content-Encoding, que en este caso tiene el valor gzip. Este encabezado indica el tipo de compresión aplicada al cuerpo del mensaje antes de ser enviado desde el servidor al cliente. En otras palabras, el servidor ha comprimido el contenido usando el algoritmo gzip para reducir el tamaño de la respuesta y optimizar la velocidad de transferencia.

El flujo de este proceso es sencillo: el servidor comprime el contenido (por ejemplo, una página HTML o un archivo JSON) y envía junto a la respuesta el encabezado Content-Encoding: gzip. Cuando el navegador recibe la respuesta, detecta este encabezado, descomprime el contenido automáticamente y luego lo interpreta normalmente según su tipo (Content-Type).

Entre los métodos de compresión más comunes encontramos:

gzip: el más ampliamente usado, eficiente y compatible.
deflate: similar a gzip, aunque menos común hoy en día.
br (Brotli): un algoritmo más moderno y con mejor compresión, utilizado principalmente en conexiones HTTPS.

Desde una perspectiva de seguridad y pentesting, este encabezado también tiene implicaciones interesantes. Aunque la compresión mejora el rendimiento, en algunos escenarios puede exponer vulnerabilidades como ataques de compresión (por ejemplo, BREACH o CRIME). Estos ataques aprovechan el hecho de que los datos comprimidos pueden filtrar información sensible, como tokens de sesión o cookies, cuando se combinan con ciertas técnicas de inyección y observación de respuestas comprimidas.

Por este motivo, en aplicaciones críticas o que manejan datos sensibles, se recomienda deshabilitar la compresión en respuestas que incluyan información confidencial, especialmente cuando se transmiten junto con datos controlados por el usuario.

En resumen, el encabezado Content-Encoding indica que la respuesta fue comprimida antes de ser enviada, lo que ayuda a mejorar la velocidad y eficiencia del tráfico HTTP. En este caso, gzip representa un método seguro y estándar de compresión, aunque debe usarse con cuidado para evitar fugas de información en entornos donde se manipulen datos sensibles.

Encabezado del servidor de respuesta HTTP

El encabezado del servidor muestra el banner del servidor web, por ejemplo, Apache, Nginx, IIS, etc. Google utiliza un banner de servidor web personalizado: gws (Servidor web de Google).

Ejemplo: Server: nginx – Este encabezado muestra qué tipo de software de servidor gestiona la solicitud. Es útil para la depuración, pero también puede revelar información del servidor que podría ser útil para los atacantes, por lo que muchos lo eliminan u ocultan.

La imagen muestra una respuesta HTTP en la que se resalta el encabezado Server, cuyo valor es gws. Este encabezado tiene como función principal identificar el software del servidor web que ha generado la respuesta. En este caso, gws (Google Web Server) es una abreviatura utilizada por Google para indicar que la respuesta proviene de su propia infraestructura de servidores.

El encabezado Server suele contener información sobre el tipo y la versión del servidor utilizado, por ejemplo:

Server: Apache/2.4.54 (Ubuntu)
Server: nginx/1.22.0
Server: Microsoft-IIS/10.0
Server: gws (como en este caso, perteneciente a Google)

Aunque este encabezado puede parecer inocuo, desde la perspectiva de la seguridad y el pentesting es un punto clave en la fase de fingerprinting, es decir, en la identificación de tecnologías y versiones utilizadas por un servidor. Conocer el tipo y versión exacta del software puede permitir a un atacante buscar vulnerabilidades conocidas o exploits específicos para ese entorno. Por ejemplo, si un servidor indica “Apache/2.2.15”, un pentester podría comprobar si esa versión tiene vulnerabilidades públicas sin parchear.

Por ese motivo, una buena práctica en entornos de producción es ocultar o modificar el valor del encabezado Server para no revelar información sensible. Esto puede lograrse configurando el servidor para que devuelva un valor genérico (por ejemplo, Server: secure o Server: webapp) o eliminando completamente el encabezado de la respuesta.

Además, en algunas auditorías es útil comparar este encabezado con otros como X-Powered-By, Via o Set-Cookie, ya que en conjunto pueden revelar más detalles sobre la infraestructura subyacente (por ejemplo, si se usa un proxy inverso, un balanceador o un framework específico).

En resumen, el encabezado Server identifica el software que atiende la petición HTTP, en este caso gws, propio de Google. Aunque es útil para fines técnicos y de diagnóstico, representa también un posible vector de exposición de información, por lo que en seguridad web se recomienda siempre minimizar o enmascarar los datos que revela.

Longitud del contenido: Al enviar datos a un servidor web, como en un formulario, la longitud del contenido indica al servidor la cantidad de datos que debe esperar en la solicitud. De esta forma, el servidor puede garantizar que no falte ningún dato.

Otros encabezados de respuesta comunes

Además de los esenciales, existen otros encabezados comunes que dan instrucciones adicionales al cliente o navegador y ayudan a controlar cómo se debe manejar la respuesta.

Cookie

Cookie: Datos enviados al servidor para ayudar a recordar tu información.

La imagen explica de manera sencilla cómo funciona el mecanismo de cookies HTTP, uno de los pilares del manejo de sesiones en la web. En la primera parte, el navegador realiza una petición inicial (GET /my-cats) al servidor. El servidor responde con un código 200 OK e incluye en los encabezados una instrucción Set-Cookie, por ejemplo:

Set-Cookie: user=b0rk; HttpOnly.

Este encabezado le dice al navegador que guarde una cookie llamada user con el valor b0rk. Además, pueden añadirse opciones de seguridad o configuración como la fecha de expiración, el atributo Secure (para enviar la cookie solo por HTTPS), SameSite (para mitigar ataques CSRF) o HttpOnly (para evitar que JavaScript acceda a la cookie).

A partir de ese momento, en cada nueva petición al mismo dominio, el navegador envía automáticamente la cookie guardada dentro del encabezado Cookie. En el ejemplo, la siguiente solicitud incluiría:

Cookie: user=b0rk.

Gracias a esto, el servidor puede reconocer al usuario sin necesidad de que se autentique de nuevo. En la práctica, así es como funcionan las sesiones de usuario, los carritos de compra y las preferencias personalizadas en la mayoría de los sitios web.

Desde el punto de vista del pentesting y la seguridad, las cookies representan un componente crítico, ya que suelen almacenar identificadores de sesión o tokens de autenticación. Si una cookie no está bien protegida, un atacante podría robarla o manipularla para suplantar la identidad de un usuario. Por eso es fundamental implementar medidas como:

HttpOnly: impide que JavaScript lea la cookie, protegiendo frente a ataques XSS.
Secure: obliga a enviar la cookie solo por conexiones HTTPS cifradas.
SameSite: restringe el envío de cookies en solicitudes entre sitios, mitigando ataques CSRF.
Expiración y renovación adecuadas: evita sesiones persistentes indefinidamente.

En resumen, la imagen muestra el ciclo básico de cómo el servidor crea y gestiona una cookie para identificar al usuario, y cómo el navegador la devuelve automáticamente en las solicitudes posteriores. Este intercambio es clave para mantener sesiones activas, aunque también constituye un punto sensible que requiere configuraciones de seguridad adecuadas para evitar la exposición o manipulación de datos de autenticación.

Set-Cookie

Información para almacenar que se envía de vuelta al servidor web en cada solicitud.}

Ejemplo: Set-Cookie: sessionId=38af1337es7a8 – Este envía cookies del servidor al cliente, que las almacena y las envía de vuelta en futuras solicitudes. Para garantizar la seguridad, asegúrese de que las cookies tengan la HttpOnlymarca «No se puede acceder a ellas mediante JavaScript» y Secure»Solo se envían mediante HTTPS».

Location

Ejemplo: Location: /index.html

Esta se usa en respuestas de redirección (3xx). Indica al cliente adónde ir si el recurso se ha movido. Si los usuarios pueden modificar este encabezado durante las solicitudes, asegúrese de validarlo y desinfectarlo; de lo contrario, podría generar vulnerabilidades de redirección abiertas, donde los atacantes pueden redirigir a los usuarios a sitios web dañinos.

El cuerpo de la respuesta HTTP es donde se encuentran los datos reales (como HTML, JSON , imágenes, etc.) que el servidor envía al cliente. Para evitar ataques de inyección como Cross-Site Scripting ( XSS ), siempre limpie y escape cualquier dato (especialmente el contenido generado por el usuario) antes de incluirlo en la respuesta.

Cookies?

Probablemente ya hayas oído hablar de las cookies; son simplemente pequeños fragmentos de datos que se almacenan en tu equipo. Se guardan al recibir un encabezado «Set-Cookie» de un servidor web. Con cada nueva solicitud, enviarás los datos de las cookies al servidor web. Dado que HTTP no registra tus solicitudes anteriores, las cookies pueden usarse para recordarle al servidor web quién eres, algunas configuraciones personales del sitio web o si ya has visitado el sitio web. Veamos un ejemplo en donde en THM explican perfectamente la solicitud HTTP :

La imagen muestra de forma muy clara y paso a paso cómo funciona el intercambio de cookies entre un cliente (navegador) y un servidor web, ilustrando el proceso de creación, almacenamiento y uso de una cookie para mantener la identificación del usuario entre distintas peticiones.

Primera solicitud (GET / HTTP/1.1): El cliente envía una petición al servidor (http://cookies.thm) solicitando una página. En esta primera interacción, aún no existe ninguna cookie almacenada en el navegador.
Respuesta del servidor (200 OK): El servidor responde con una página HTML que contiene un formulario, pidiendo al usuario que introduzca su nombre. En los encabezados de esta respuesta se incluyen detalles típicos como Server: nginx/1.15.8, Date, Content-Type, etc.
Envío del formulario (POST / HTTP/1.1): El usuario completa el formulario escribiendo su nombre (“adam”) y el navegador envía esta información al servidor usando el método POST, con el cuerpo name=adam. Esta información viaja en el contenido de la solicitud (body) con el tipo application/x-www-form-urlencoded.
Creación de la cookie (Set-Cookie): El servidor procesa la información recibida y responde con otro 200 OK, pero esta vez incluye el encabezado Set-Cookie: name=adam. Este encabezado indica al navegador que debe almacenar esa cookie localmente con el par clave-valor (name=adam).
Solicitud posterior con cookie (GET / HTTP/1.1): En la siguiente petición que el navegador hace al mismo dominio, automáticamente adjunta la cookie guardada en el encabezado Cookie: name=adam. Este proceso ocurre sin intervención del usuario: el navegador se encarga de enviar las cookies que correspondan al dominio de destino.
Respuesta personalizada: El servidor recibe la cookie y reconoce al usuario gracias al valor almacenado. En este caso, en lugar de mostrar el formulario nuevamente, responde con un mensaje personalizado:
<html><body>Welcome back adam</body></html>

De esta forma, el servidor sabe quién es el cliente sin necesidad de volver a pedir sus datos. Desde el punto de vista del pentesting y la seguridad, este flujo demuestra cómo las cookies permiten mantener sesiones activas, pero también evidencia posibles puntos vulnerables. Si el valor de la cookie (name=adam) no está protegido o firmado, un atacante podría manipularla para cambiar su contenido, suplantar usuarios o acceder a información restringida. Además, si no se configuran correctamente atributos de seguridad como HttpOnly, Secure o SameSite, la cookie podría ser robada mediante ataques XSS o CSRF.

En resumen, la imagen describe de forma completa el ciclo de vida de una cookie: desde su creación mediante Set-Cookie hasta su reenvío automático con cada solicitud. Este mecanismo es esencial para el manejo de sesiones, autenticación y personalización en la web, pero también representa un vector crítico que debe protegerse adecuadamente para evitar vulnerabilidades y fugas de información.

Encabezados de seguridad

Los encabezados de seguridad HTTP ayudan a mejorar la seguridad general de la aplicación web al mitigar ataques como Cross-Site Scripting ( XSS ), clickjacking y otros. A continuación, analizaremos en profundidad los siguientes encabezados de seguridad:

Política de seguridad de contenido ( CSP )
Seguridad Estricta en el Transporte (HSTS)
Opciones de tipo de contenido X
Política de referencias

Puedes usar un sitio como https://securityheaders.io/ para analizar los encabezados de seguridad de cualquier sitio web.

Política de seguridad de contenido ( CSP )

Un encabezado CSP es una capa de seguridad adicional que puede ayudar a mitigar ataques comunes como el Cross-Site Scripting ( XSS ). El código malicioso podría alojarse en un sitio web o dominio independiente e inyectarse en el sitio web vulnerable. Un CSP permite a los administradores indicar qué dominios o fuentes se consideran seguros y proporciona una capa de mitigación ante dichos ataques. Dentro del encabezado, puede ver propiedades como » default-srco» o script-src»definidas» y muchas más. Cada una de estas permite al administrador definir, con distintos niveles de detalle, qué dominios están permitidos para cada tipo de contenido. El uso de «self» es una palabra clave especial que refleja el mismo dominio en el que está alojado el sitio web.

La imagen ilustra un comportamiento clave del navegador relacionado con la política del mismo origen (Same-Origin Policy) y cómo ésta se aplica cuando un sitio malicioso intenta enviar peticiones a otro dominio utilizando las cookies del usuario.

En el ejemplo, un script alojado en evil.com le indica al navegador que envíe una petición GET a mail.google.com utilizando las cookies de sesión que el usuario ya tiene guardadas en su navegador. Sorprendentemente, el navegador sí realiza la solicitud, porque las cookies están asociadas a mail.google.com, y las reglas de seguridad del navegador permiten incluirlas automáticamente siempre que la petición se dirija al dominio correcto.

Sin embargo, la parte importante —y la que evita una vulnerabilidad crítica— es que el navegador no permite al sitio malicioso ver la respuesta, a menos que el servidor (mail.google.com) explícitamente autorice el intercambio de datos entre dominios mediante los encabezados CORS (Cross-Origin Resource Sharing). Es decir, aunque evil.com puede provocar la solicitud, no puede acceder al contenido devuelto por mail.google.com. Esto evita que un atacante robe información sensible, como correos, datos personales o tokens de sesión.

Este mecanismo es la base de protección frente a ataques conocidos como CSRF (Cross-Site Request Forgery), en los que un atacante intenta ejecutar acciones en nombre de un usuario autenticado sin que éste lo sepa. El navegador incluye las cookies en la petición, pero la aplicación objetivo debe implementar validaciones adicionales (por ejemplo, tokens CSRF o cabeceras de verificación) para asegurarse de que la solicitud proviene realmente del sitio legítimo.

En resumen, la imagen demuestra cómo el navegador protege la confidencialidad de las respuestas entre diferentes orígenes. Aunque una página maliciosa puede inducir al navegador a hacer peticiones autenticadas con las cookies del usuario, no podrá leer la respuesta ni acceder a los datos a menos que el servidor lo permita explícitamente. Este principio es uno de los pilares de la seguridad en la web moderna, y su correcta comprensión es esencial en el análisis de vulnerabilidades de tipo CORS y CSRF.

Observando un ejemplo de encabezado CSP

Content-Security-Policy: default-src ‘self’; script-src ‘self’ https://cdn.laprovittera.com; style-src ‘self’

Vemos el uso de:

default-src : que especifica la política predeterminada de self, lo que significa solo el sitio web actual.
script-src: – que especifica la política sobre dónde se pueden cargar los scripts, que es self junto con los scripts alojados enhttps://cdn.laprovittera.com
style-src – que especifica la política sobre dónde se pueden cargar las hojas de estilo CSS desde el sitio web actual (auto)

La imagen muestra una situación en la que un sitio malicioso (evil.com) intenta enviar una petición POST a otro dominio (secrets.corp.company.com/send_money) utilizando JavaScript, pero el navegador bloquea el intento debido a la política del mismo origen (Same-Origin Policy, SOP).

Esta política es uno de los mecanismos de seguridad más importantes en los navegadores, ya que impide que un sitio web ejecute peticiones o acceda a datos de otro dominio sin autorización explícita. En este caso, el navegador responde diciendo:

“¡No! Same origin policy! I’m not even going to make that request without checking first”

Esto significa que, antes de permitir que un script en evil.com realice una solicitud POST hacia secrets.corp.company.com, el navegador debe verificar si el servidor de destino autoriza el intercambio mediante los encabezados CORS (Cross-Origin Resource Sharing).

El proceso normal sería que el navegador realice primero una petición de preflight (preverificación), enviando una solicitud OPTIONS al dominio de destino. Esta petición pregunta si el servidor permite recibir solicitudes desde evil.com con el método POST y los encabezados especificados. Solo si el servidor responde con los encabezados CORS apropiados (por ejemplo, Access-Control-Allow-Origin: evil.com), el navegador continuará con la petición real. Si no hay respuesta válida, el navegador bloquea la solicitud automáticamente.

Este comportamiento evita que un atacante pueda ejecutar acciones sensibles en nombre de un usuario autenticado, como enviar dinero o modificar datos, sin el conocimiento del usuario o del servidor. En otras palabras, protege contra ataques CSRF y abusos de CORS, donde se intenta usar las credenciales del usuario (cookies, tokens) en un contexto no autorizado.

En resumen, la imagen representa el principio de seguridad que impide que sitios de distintos orígenes interactúen libremente entre sí. El navegador actúa como un guardián que verifica primero las políticas del servidor antes de ejecutar una petición potencialmente peligrosa. Gracias a la Same-Origin Policy y las validaciones CORS, los navegadores modernos pueden prevenir que sitios maliciosos realicen acciones no autorizadas en dominios legítimos.

Seguridad Estricta en el Transporte (HSTS)

El encabezado HSTS garantiza que los navegadores web siempre se conecten mediante HTTPS. Veamos un ejemplo de HSTS: Strict-Transport-Security: max-age=63072000; includeSubDomains; preload A continuación se muestra un desglose del encabezado HSTS de ejemplo por directiva:

max-age : este es el tiempo de expiración en segundos para esta configuración
includeSubDomains : una configuración opcional que indica al navegador que también aplique esta configuración a todos los subdominios.
Precarga : Esta configuración opcional permite incluir el sitio web en las listas de precarga. Los navegadores pueden usarlas para aplicar HSTS incluso antes de su primera visita al sitio web.

Opciones de tipo de contenido X

El encabezado X-Content-Type-Options se puede usar para indicar a los navegadores que no adivinen la fecha MIME de un recurso, sino que solo usen el encabezado Content-Type. A continuación, se muestra un ejemplo:

X-Content-Type-Options: nosniff

A continuación se muestra un desglose del encabezado X-Content-Type-Options por directivas:

Nosniff esta directiva le indica al navegador que no detecte ni adivine el tipo MIME .

Política de referencias

Este encabezado controla la cantidad de información que se envía al servidor web de destino cuando un usuario es redirigido desde el servidor web de origen, como al hacer clic en un hipervínculo. Este encabezado permite al administrador web controlar la información que se comparte. A continuación, se muestran algunos ejemplos de la Política de Referencia:

Referrer-Policy: no-referrer Esto deshabilita por completo cualquier información que se envíe sobre el referente
Referrer-Policy: same-origin Mismo origen : Esta política solo enviará información de referencia cuando el destino forme parte del mismo origen. Esto es útil cuando se desea que la información de referencia se transmita cuando los hipervínculos se encuentran dentro del mismo sitio web, pero no a sitios web externos.

Referrer-Policy: strict-origin origen estricto : esta política solo envía el referente como origen cuando el protocolo permanece invariable. Por lo tanto, se envía un referente cuando una conexión HTTPS se conecta a otra conexión HTTPS.
Referrer-Policy: strict-origin-when-cross-origin es similar a strict-origin excepto para solicitudes del mismo origen, donde envía la ruta URL completa en el encabezado de origen.

La imagen representa de forma muy clara cómo un navegador decide si permite o no una solicitud entre diferentes orígenes, siguiendo las reglas del mecanismo CORS (Cross-Origin Resource Sharing). Este proceso es fundamental para mantener la seguridad en la web y evitar que un sitio malicioso (como evil.com) acceda libremente a los recursos o datos de otro dominio (por ejemplo, api.company.com).

El flujo comienza con una petición que un script en evil.com intenta realizar hacia otra URL. El navegador analiza la solicitud y pasa por varios pasos de validación:

¿Coincide exactamente el origen?
Si la solicitud proviene del mismo dominio, puerto y protocolo (por ejemplo, de https://example.com a https://example.com), entonces el navegador permite la petición sin restricciones.
Pero si los orígenes no coinciden exactamente, se activa la verificación CORS. Por defecto, el navegador bloquea el acceso entre orígenes distintos hasta confirmar que el servidor de destino lo permite explícitamente.
¿El tipo de solicitud está permitido desde otro origen?
Algunos tipos de solicitudes son considerados seguros y se permiten sin comprobaciones adicionales, como las de recursos estáticos (<img src>, <link rel=»stylesheet»>, <script src>). En esos casos, el navegador las marca como allowed.
Si no se trata de un tipo permitido, continúa al siguiente paso.
¿Es una “simple request”?
Una solicitud “simple” en CORS es, por ejemplo, una GET o POST sin cuerpo complejo ni cabeceras personalizadas (como Authorization o Content-Type no estándar).
Si la solicitud es simple, el navegador la envía directamente y luego evalúa si la respuesta contiene los encabezados CORS adecuados (por ejemplo, Access-Control-Allow-Origin).
Si no es una simple request → realizar una preflight (OPTIONS)
Para solicitudes más complejas (por ejemplo, con métodos PUT, DELETE o cabeceras personalizadas), el navegador primero envía una petición OPTIONS al servidor, llamada preflight request. Esta sirve para preguntar:
“¿Me permites enviar esta solicitud desde otro dominio?”
El servidor debe responder con los encabezados apropiados (Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, etc.).
Evaluación de los encabezados de la respuesta
Si el servidor autoriza el origen en su respuesta, el navegador procede con la solicitud real y la marca como allowed.
Si no, el navegador bloquea la petición (DENIED) y no permite que el sitio atacante vea ni interactúe con la respuesta.

En resumen, esta imagen explica visualmente cómo los navegadores implementan las reglas de CORS para proteger la información entre dominios.

Aunque un sitio malicioso puede intentar hacer peticiones a otro origen, el navegador solo las completará si el servidor explícitamente lo autoriza mediante los encabezados CORS.

Este sistema previene ataques de tipo data theft, CSRF avanzado y exfiltración de información, manteniendo el principio de aislamiento entre sitios web que es esencial para la seguridad del ecosistema web.

Resumen del capítulo

Estructura general de una respuesta HTTP

Una respuesta HTTP está formada por:

Status-Line: indica el protocolo, el código y el estado textual (HTTP/1.1 200 OK).
Encabezados (headers): metadatos que explican cómo manejar la respuesta.
Línea en blanco (\r\n): separa los encabezados del cuerpo.
Cuerpo (body): contiene el contenido real (HTML, JSON, imagen, etc.).

Encabezados de respuesta más comunes

🔹 Date

Muestra la fecha y hora exactas en que el servidor generó la respuesta.

Utilidad técnica: permite sincronizar la caché y controlar la validez de la información.
Desde la seguridad: diferencias de tiempo pueden revelar desincronización entre servidores o indicar balanceo de carga (útil para fingerprinting).

🔹 Cache-Control

Controla cómo el navegador o intermediarios almacenan los recursos.

Ejemplos comunes:
- public: almacenable en cachés compartidas.
- private: solo en el cliente.
- no-cache / no-store: evita almacenar datos sensibles.
Riesgo: si se permiten cachés públicas para contenido con información de usuario, se puede filtrar información privada.

🔹 ETag

Identificador único de una versión de recurso.

Ventaja: mejora rendimiento evitando descargas innecesarias.
Riesgos: puede revelar hashes predecibles, permitir tracking o fuga de datos internos del servidor.

🔹 Content-Type

Indica el tipo de contenido (text/html, application/json, etc.) y la codificación (charset=UTF-8).

Importancia: evita errores de interpretación del navegador.
Riesgo: un Content-Type incorrecto puede permitir ataques MIME sniffing o XSS.
Mitigación: incluir también X-Content-Type-Options: nosniff.

🔹 Content-Encoding

Indica si el contenido fue comprimido (gzip, deflate, br).

Beneficio: acelera la carga.
Riesgo: ataques como BREACH o CRIME pueden filtrar datos sensibles cuando se combinan con compresión y cifrado.
Recomendación: desactivar compresión en respuestas con datos confidenciales.

🔹 Server

Muestra el software y la versión del servidor (Apache/2.4.54, nginx/1.22.0, gws).

Riesgo: revela tecnologías y versiones vulnerables (útil para fingerprinting).
Mitigación: ocultar o modificar el banner (Server: secure o eliminarlo).

Cookies y Set-Cookie

Las cookies permiten mantener sesiones activas y recordar usuarios.

Ejemplo: Set-Cookie: sessionId=38af1337es7a8; HttpOnly; Secure; SameSite=Strict
Atributos importantes:
- HttpOnly: impide acceso por JavaScript (mitiga XSS).
- Secure: solo envía cookies por HTTPS.
- SameSite: evita envíos automáticos en peticiones cross-site (mitiga CSRF).
Riesgo: cookies sin protección pueden ser robadas o manipuladas.

Redirecciones y Location

Usado en respuestas 3xx para redirigir al cliente (Location: /index.html).

Riesgo: si el valor puede manipularse, puede derivar en un Open Redirect (redirección hacia sitios maliciosos).
Recomendación: validar y sanitizar siempre los valores de Location.

Encabezados de seguridad

Estos headers fortalecen la defensa de la aplicación ante ataques comunes:

CSP (Content-Security-Policy):
Define qué fuentes son válidas para scripts, estilos, imágenes, etc.
- Ejemplo:
  Content-Security-Policy: default-src ‘self’; script-src ‘self’ https://cdn.laprovittera.com; style-src ‘self’
- Previene: XSS y carga de recursos maliciosos.
HSTS (Strict-Transport-Security):
Obliga al navegador a usar HTTPS siempre.
- Ejemplo:
  Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-Content-Type-Options:
Evita que el navegador adivine tipos MIME.
- Ejemplo: X-Content-Type-Options: nosniff
Referrer-Policy:
Controla cuánta información se comparte del origen al navegar entre sitios.
- Ejemplo: Referrer-Policy: no-referrer

CORS y Same-Origin Policy

Los navegadores impiden que sitios de distintos orígenes intercambien datos libremente.

Protege contra: CSRF y fugas de información.
Flujo básico:
- Si la petición es de un origen distinto, el navegador envía una verificación (preflight OPTIONS).
- El servidor debe responder con los encabezados adecuados (Access-Control-Allow-Origin, etc.) para permitirla.
- Si no lo hace, el navegador bloquea la solicitud.

10 Preguntas Basadas en el Artículo

¿Qué representa la primera línea de una respuesta HTTP y qué información contiene?
¿Para qué sirve el encabezado Date en una respuesta HTTP y cómo puede usarse en un análisis de seguridad?
¿Qué indica el encabezado Cache-Control: no-store y en qué casos es esencial usarlo?
¿Cómo funciona el encabezado ETag y qué tipo de riesgos puede presentar si no se gestiona adecuadamente?
¿Qué información ofrece el encabezado Content-Type y por qué es fundamental en términos de seguridad?
¿Qué riesgos de seguridad puede implicar el encabezado Server en una respuesta HTTP?
¿Qué tipo de ataques podrían beneficiarse del mal uso de la compresión especificada en Content-Encoding?
¿Cómo funciona una cookie en una respuesta HTTP y qué encabezado se utiliza para definirla?
¿Qué función cumple el encabezado Strict-Transport-Security y qué directivas importantes puede incluir?
¿Cómo protege la política del mismo origen (Same-Origin Policy) frente a ataques CSRF y cómo se relaciona con los encabezados CORS?

Respuestas Detalladas a las 10 Preguntas

1. ¿Qué representa la primera línea de una respuesta HTTP y qué información contiene?

La primera línea se llama status-line y contiene:

La versión del protocolo (por ejemplo, HTTP/1.1),
El código de estado (como 200, 404, etc.),
El mensaje descriptivo (como OK, Not Found, etc.).
Esta línea le indica al navegador si la solicitud fue exitosa o si ocurrió un error.

2. ¿Para qué sirve el encabezado Date en una respuesta HTTP y cómo puede usarse en un análisis de seguridad?

Este encabezado indica la fecha y hora exacta en la que el servidor generó la respuesta.

En seguridad, puede usarse para:

Detectar desincronización de relojes en sistemas distribuidos.
Inferir si hay varios servidores backend con configuraciones distintas.
Identificar proxies que modifican la fecha.

3. ¿Qué indica el encabezado Cache-Control: no-store y en qué casos es esencial usarlo?

Indica que ninguna parte de la respuesta debe almacenarse en la caché, ni en el navegador ni en intermediarios.

Es esencial cuando:

Se trata de datos sensibles como tokens, información personal o formularios de login.
Se quiere evitar que otros usuarios accedan a contenido privado desde la caché.

4. ¿Cómo funciona el encabezado ETag y qué tipo de riesgos puede presentar si no se gestiona adecuadamente?

ETag actúa como una identificación única de una versión del recurso. Permite que el navegador consulte si el recurso ha cambiado, para evitar descargas innecesarias.

Riesgos:

Seguimiento persistente de usuarios (tracking por ETag).
Exposición de información interna del sistema si el valor del ETag revela detalles como rutas o hashes.

5. ¿Qué información ofrece el encabezado Content-Type y por qué es fundamental en términos de seguridad?

Informa al navegador sobre el tipo de contenido de la respuesta (ej. HTML, JSON, etc.) y su codificación (ej. UTF-8).

Importancia en seguridad:

Un Content-Type incorrecto puede permitir ataques XSS si el navegador interpreta scripts no deseados.
Se debe usar con X-Content-Type-Options: nosniff para evitar detección de MIME.

6. ¿Qué riesgos de seguridad puede implicar el encabezado Server en una respuesta HTTP?

Este encabezado puede revelar:

El tipo y versión del software del servidor (ej. Apache/2.4.54).
Tecnologías usadas que pueden tener vulnerabilidades conocidas.
Un atacante puede utilizar esta información para aplicar exploits específicos o técnicas de fingerprinting.

7. ¿Qué tipo de ataques podrían beneficiarse del mal uso de la compresión especificada en Content-Encoding?

Ataques como:

BREACH
CRIME
Estos explotan la compresión (por ejemplo, gzip) para filtrar datos sensibles como cookies o tokens, cuando se combinan con contenido controlado por el atacante.

8. ¿Cómo funciona una cookie en una respuesta HTTP y qué encabezado se utiliza para definirla?

El servidor envía una cookie usando Set-Cookie. El navegador almacena esta cookie y la enviará automáticamente en solicitudes posteriores al mismo dominio.

Ejemplo:

Set-Cookie: sessionId=abc123; HttpOnly; Secure

9. ¿Qué función cumple el encabezado Strict-Transport-Security y qué directivas importantes puede incluir?

Fuerza al navegador a usar siempre HTTPS al comunicarse con el sitio.

Directivas:

max-age: duración en segundos de la política.
includeSubDomains: aplica a todos los subdominios.
preload: para inclusión en listas precargadas de navegadores.

10. ¿Cómo protege la política del mismo origen (Same-Origin Policy) frente a ataques CSRF y cómo se relaciona con los encabezados CORS?

Impide que scripts de un dominio accedan a recursos de otro dominio sin permiso.

CORS (Cross-Origin Resource Sharing) es el mecanismo que permite excepciones controladas, mediante encabezados como:

Access-Control-Allow-Origin

Esto asegura que solo orígenes autorizados puedan acceder a los recursos.

10 Ejercicios Basados en el Contenido

Dado este encabezado: Content-Type: application/json, ¿cómo debería el navegador interpretar el contenido?
Observa este encabezado: Cache-Control: public, max-age=86400. Explica su función y posibles riesgos.
Si un servidor responde con ETag: «abc123» y el navegador envía If-None-Match: «abc123», ¿qué código debería devolver el servidor si el contenido no cambió?
¿Qué encabezado deberías añadir para que el navegador no adivine el tipo de contenido?
¿Qué valores debes añadir a una cookie para que solo se envíe por HTTPS y no sea accesible por JavaScript?
Analiza el siguiente encabezado:
Strict-Transport-Security: max-age=31536000; includeSubDomains
¿Qué hace y por cuánto tiempo?
Describe cómo funcionaría una redirección con el encabezado Location y código 301.
Si el encabezado Server revela “Apache/2.2.3 (CentOS)”, ¿qué deberías investigar como pentester?
¿Qué hace el encabezado Content-Encoding: br y qué ventaja ofrece sobre gzip?
¿Qué encabezado CORS debe estar presente para permitir solicitudes desde el dominio https://evil.com?

Respuestas a los Ejercicios

1. El navegador debe interpretar que el contenido es JSON estructurado y no HTML ni texto plano. Lo usará como objeto de datos.

2. Permite que la respuesta sea almacenada en cachés públicas durante 86400 segundos (24 horas).

Riesgo: si incluye datos sensibles, pueden ser accesibles por otros usuarios o proxies.

3. El servidor debería devolver:

HTTP/1.1 304 Not Modified

Indicando que el recurso no ha cambiado desde la última solicitud.

X-Content-Type-Options: nosniff

Evita que el navegador adivine el tipo MIME.

Set-Cookie: sessionId=xyz; Secure; HttpOnly

Secure: solo HTTPS.
HttpOnly: no accesible por JavaScript.

6. El navegador solo usará HTTPS durante 1 año (31536000 segundos) y también aplica esta política a todos los subdominios.

7. Un servidor responde con:

HTTP/1.1 301 Moved Permanently
Location: https://nuevo-dominio.com

El navegador redirige automáticamente a la nueva URL.

8. Debes investigar:

Si esa versión de Apache tiene vulnerabilidades conocidas (CVEs).
Si CentOS está desactualizado o sin soporte.
Esto podría permitir explotar vulnerabilidades públicas.

Content-Encoding: br indica que el contenido fue comprimido con Brotli, un algoritmo más eficiente que gzip. Reduce aún más el tamaño de la respuesta y mejora la velocidad de carga.

10. El servidor debe incluir:

Access-Control-Allow-Origin: https://evil.com

Esto permite que evil.com acceda a los recursos, si así se autoriza explícitamente.

Despedida — lo que aprendiste y por qué es vital

Con este capítulo ya sabes leer y entender a fondo las respuestas HTTP, reconocer los encabezados más importantes y detectar cuándo su configuración puede ser un riesgo. Aprendiste a identificar banners de servidor, políticas de caché inseguras, cookies mal protegidas, redirecciones manipulables y a evaluar la presencia o ausencia de cabeceras de seguridad como CSP o HSTS. Esto te permitirá, como futuro pentester, realizar auditorías más precisas y detectar vulnerabilidades reales a nivel de servidor y aplicación web. Cada encabezado que veas ahora dejará de ser solo “texto técnico” y se convertirá en una fuente de inteligencia para tus pruebas.

Respuesta a una solicitud HTTP