En este capítulo, Códigos de estado HTTP, aprenderás cómo responde un servidor web a una solicitud HTTP y por qué comprender la estructura y el significado de una response es imprescindible para un hacker ético o pentester. Verás qué contiene la status-line (código de estado), cuáles son los encabezados de respuesta más importantes (Content-Type, Cache-Control, Set-Cookie, Server, Strict-Transport-Security, etc.), cómo se estructura el body, y qué pistas útiles (o peligrosas) puede revelar cada campo durante una auditoría. Esto es útil porque muchos hallazgos reales —fingerprinting, filtración de información en páginas de error, fallos de caché, cookies mal configuradas o la ausencia de cabeceras de seguridad— se detectan inspeccionando respuestas con detalle.
Respuesta a una solicitud HTTP
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.
La respuesta HTTP contiene varios elementos: una línea de estado con el código de resultado (por ejemplo, 200 OK o 404 Not Found), los encabezados (headers) que aportan información adicional como el tipo de contenido, la longitud o directivas de caché, y finalmente el cuerpo (body), que es el contenido solicitado —una página HTML, una imagen, un archivo, o incluso un mensaje de error.
En el contexto del pentesting, entender este flujo es esencial, ya que muchos ataques o pruebas de seguridad se basan precisamente en analizar cómo responde el servidor. Por ejemplo, los códigos de estado pueden revelar detalles sobre configuraciones internas (un 403 indica restricciones de acceso, un 500 puede mostrar errores de backend), y los encabezados de seguridad como Content-Security-Policy, Strict-Transport-Security o X-Frame-Options ayudan a evaluar si una aplicación está correctamente protegida frente a ataques comunes.
En resumen, esta imagen ilustra el paso final de la comunicación HTTP, donde el servidor devuelve el resultado de la solicitud al navegador. Comprender este intercambio es fundamental para detectar vulnerabilidades, interpretar respuestas del servidor y analizar el comportamiento de las aplicaciones web durante una auditoría de seguridad.
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.
La imagen muestra una respuesta HTTP completa desglosada en sus partes esenciales: la status line en la parte superior (HTTP/1.1 200 OK), seguida de varios encabezados (headers) que describen metadatos sobre la respuesta, y finalmente el cuerpo (body) con el contenido real (en la ilustración un pequeño ASCII-art de un gato). Visualmente se enfatiza que el número de estado (200) indica éxito, que los headers comunican información sobre caché, tipo de contenido, longitud y seguridad, y que el body es lo que el cliente realmente consume una vez procesada la respuesta.
Entre los encabezados representados hay varios que son especialmente relevantes: Content-Type indica el MIME del cuerpo (text/plain; charset=UTF-8), Content-Length dice cuántos bytes esperar, Cache-Control y Age controlan políticas de caché y la frescura del recurso, ETag sirve para validaciones condicionales y ahorro de ancho de banda, Strict-Transport-Security (HSTS) obliga al navegador a usar HTTPS, y Server revela la tecnología usada en el backend (en el ejemplo: Netlify). Todos estos campos son metadata funcional que permite al cliente manejar la respuesta correctamente, optimizar rendimiento y aplicar políticas de seguridad en el lado del navegador o de intermediarios.
El header Server y otros metadatos facilitan el fingerprinting y pueden dar pistas sobre versiones vulnerables; ETag y Cache-Control inciden en ataques de cache poisoning o en fuga de información si los proxies no están bien configurados; Strict-Transport-Security es una buena señal de endurecimiento, pero su ausencia es un hallazgo típico; Content-Type mal establecido (por ejemplo servir HTML con text/plain) puede llevar a problemas de content sniffing y XSS. Además, Content-Length y la forma en que se determinan los límites del body son elementos que suelen explotarse en ataques de request/response smuggling o en manipulación de parsers de intermediarios.
A nivel práctico recomiendo que los alumnos inspeccionen respuestas con un proxy interceptador (Burp/ZAP) para revisar headers, comparar HEAD vs GET, forzar respuestas condicionales con If-None-Match/If-Modified-Since y observar cómo cambia el flujo de caché. También es importante buscar información sensible accidental en headers o en el body (tokens, rutas internas, datos de debugging), comprobar flags de cookies (HttpOnly, Secure, SameSite) cuando existan, y verificar la coherencia entre cabeceras de seguridad (HSTS, CSP, X-Frame-Options) y la política real aplicada por el servidor o CDN.
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.
Encabezados de respuesta
Cuando un servidor web responde a una solicitud HTTP , incluye encabezados de respuesta HTTP , que son básicamente pares clave-valor. Estos encabezados proporcionan información importante sobre la respuesta e indican al cliente (normalmente el navegador) cómo gestionarla. Imagine un ejemplo de una respuesta HTTP con los encabezados resaltados. Los encabezados clave como Content-Type, Content-Length, y Datenos brindan detalles importantes sobre la respuesta que envía el servidor.
Encabezados de respuesta obligatorios Algunos encabezados de respuesta son cruciales para garantizar el correcto funcionamiento de la respuesta HTTP . Proporcionan información esencial que tanto el cliente como el servidor necesitan para procesar todo correctamente. A continuación, se presentan algunos importantes:
- Fecha : Ejemplo: Date: Fri, 17 feb 2024 10:43:21 GMT este encabezado muestra la fecha y hora exactas en que el servidor generó la respuesta.
- Content-Type : 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.
- Servidor : 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.
- Set-Cookie : 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 HttpOnly marca «No se puede acceder a ellas mediante JavaScript» y Secure «Solo se envían mediante HTTPS».
- Control de caché : 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).
- Ubicación : 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.
Cuerpo de la respuesta (opcional)
El cuerpo de la respuesta contiene el contenido real de la respuesta. Por ejemplo, en el caso de una página HTML, el cuerpo de la respuesta contendrá el marcado HTML. 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.
Ejemplo de respuesta HTTP
- El siguiente fragmento de código es un ejemplo de una respuesta típica de un servidor web.
- Nota: El cuerpo de la respuesta/contenido de la página se ha omitido ya que no es relevante en este momento.
- Inspeccionemos algunos de estos encabezados de respuesta HTTP con mayor detalle
La imagen muestra una respuesta HTTP completa, desglosada en sus partes principales: el código de estado, los encabezados y el cuerpo del mensaje. En este caso, el servidor devuelve un estado 200 OK, lo que significa que la solicitud del cliente fue procesada correctamente y el contenido solicitado está disponible.
En la primera línea se indica el protocolo y el código de estado (HTTP/1.1 200 OK). A continuación aparecen los encabezados (headers), que contienen información sobre la respuesta:
- Date: muestra la fecha y hora en que el servidor generó la respuesta.
- Cache-Control: define las políticas de caché; aquí, private, max-age=0 indica que el contenido no debe almacenarse en cachés compartidos y debe solicitarse cada vez.
- Content-Type: especifica el tipo de contenido devuelto y el juego de caracteres (text/html; charset=UTF-8).
- Content-Encoding: indica que el cuerpo está comprimido con gzip para optimizar la transferencia.
- Server: revela el software o tecnología del servidor, en este caso identificado como gws (Google Web Server).
- Content-Length: informa del tamaño del cuerpo del mensaje (258 bytes).
Finalmente, el bloque <PAGE CONTENT> representa el cuerpo de la respuesta (body), que contiene el contenido real que el navegador mostrará al usuario, normalmente HTML, JSON o cualquier otro tipo de dato.
Desde una perspectiva de pentesting, analizar este tipo de respuestas es crucial. Los encabezados pueden revelar información sensible o configuraciones útiles para el reconocimiento, como el tipo de servidor, detalles de codificación o políticas de caché. Por ejemplo, conocer que el contenido está comprimido (gzip) puede ser relevante para probar ataques de tipo compression oracle; el valor del header Server ayuda en el fingerprinting del backend; y la falta de cabeceras de seguridad como Strict-Transport-Security o X-Content-Type-Options puede indicar configuraciones débiles.
En resumen, esta imagen muestra la estructura clásica de una respuesta HTTP y es perfecta para comprender cómo el servidor devuelve información al cliente. Cada encabezado cumple un propósito técnico, pero también puede ofrecer pistas valiosas para un análisis de seguridad o una auditoría web.
Podrás notar que este ejemplo no es igual al dado más arriba, ni al anterior y esto es normal, pueden variar en algunos parámetros, otros son obligatorios. Veamos ahora cada una de estas partes a fondo.
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 muestra una respuesta HTTP y resalta en rojo la status-line, es decir, la primera línea de la respuesta que indica tres datos fundamentales: la versión del protocolo, el código de estado y el mensaje de estado. En este caso, la línea HTTP/1.1 200 OK señala que el servidor usa el protocolo HTTP/1.1 y que la solicitud fue procesada correctamente, devolviendo un código 200, que corresponde a una respuesta exitosa.
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.
Desde la perspectiva del pentesting, la status-line es útil para obtener información sobre cómo maneja el servidor las solicitudes. Por ejemplo, respuestas 3xx y 4xx ayudan a detectar redirecciones o errores de acceso, mientras que los códigos 5xx pueden revelar fallos internos o configuraciones incorrectas en la aplicación. Además, ciertos servidores devuelven mensajes de error personalizados que pueden filtrar datos sensibles del backend o del framework utilizado.
En resumen, la status-line es el encabezado principal de una respuesta HTTP y actúa como indicador del resultado de la comunicación. Entender su significado permite no solo interpretar el comportamiento del servidor, sino también identificar posibles puntos débiles o errores útiles en una auditoría de seguridad web.
Códigos de estado HTTP comunes
Cuando trabajas con aplicaciones web, ya sea como administrador de sitios web o como evaluador de penetración, es probable que hayas tenido que hacer una búsqueda web de un código de tres dígitos como » how to fix 404 error» y recorrer el mismo volumen de resultados de búsqueda repetidamente. Has visto este código 1001 veces pero siempre se te olvida.
Los códigos de estado HTTP son una forma estandarizada de comunicación entre cliente y servidor, que permiten entender si una solicitud fue exitosa, redirigida, denegada o falló. Para un analista de seguridad, interpretar correctamente estos códigos es fundamental para detectar comportamientos anómalos, descubrir rutas sensibles y evaluar la robustez de las respuestas del servidor.
Códigos para pruebas de seguridad de aplicaciones web
Es importante familiarizarse con los códigos de estado de los mensajes HTTP. W3Schools ofrece una muy buena explicación en https://www.w3schools.com/tags/ref_httpmessages.asp. Estos son los códigos de estado HTTP más relevantes para las pruebas de seguridad de aplicaciones web:
| CÓDIGO | SIGNIFICADO |
| 200 | OK |
| 301 | Movido permanentemente |
| 302 | Encontró |
| 400 | Solicitud incorrecta |
| 401 | No autorizado |
| 403 | Prohibido |
| 404 | Extraviado |
| 405 | Método no permitido |
| 500 | Error Interno del Servidor |
| 502 | Puerta de enlace defectuosa |
| 503 | Servicio No Disponible |
| 504 | Tiempo de espera de la puerta de enlace |
Cuando un servidor HTTP responde, la primera línea siempre contiene un código de estado que informa al cliente del resultado de su solicitud y, potencialmente, cómo gestionarla. Hay 63 códigos de estado HTTP estándar (Hoy existen más), todos los cuales se encuentran en esta hoja de referencia de códigos HTTP. Estos códigos de estado se pueden dividir en cinco rangos diferentes:
Estos códigos se denominan códigos de estado HTTP. Los servidores inundados de solicitudes suelen devolver errores 4XX o 5XX y tener demasiadas redirecciones también puede indicar problemas graves de seguridad. A partir de ahora, ya no tendrás que hacer esas búsquedas porque he preparado esta hoja de trucos sobre códigos de estado HTTP.
1XX – Respuesta de información
Se envían para informar al cliente que la primera parte de su solicitud ha sido aceptada y que debe continuar enviando el resto . Estos códigos ya no son muy comunes. Entonces cuando un servidor devuelve un código 1XX, significa que el servidor ha recibido y comprendido su solicitud, y su navegador solo necesita esperar a que el servidor termine de procesar sus datos.
| CÓDIGO | SIGNIFICADO | DESCRIPCIÓN |
| 100 | Continuar | El servidor ha recibido los encabezados de la solicitud y el cliente debe proceder a enviar el cuerpo de la solicitud. |
| 101 | Protocolos de conmutación | El solicitante ha pedido al servidor que cambie los protocolos mediante un mecanismo de actualización de protocolo , y el servidor ha aceptado. |
| 102 | Procesando | El servidor ha aceptado toda la solicitud pero aún la está procesando. |
| 103 | Early Hints | Úselo con el encabezado de enlace para precargar recursos mientras el servidor prepara una respuesta. |
2XX – Éxito
Este rango de códigos de estado se utiliza para indicar al cliente que su solicitud fue exitosa. Las solicitudes 2XX significan que los datos transmitidos han llegado al servidor o que el recurso que desea del servidor ha llegado de forma segura a su máquina.
| CÓDIGO | SIGNIFICADO | DESCRIPCIÓN |
| 200 | OK | La solicitud fue realizada con éxito. La solicitud fue exitosa y el servidor ha devuelto los datos solicitados. |
| 201 | Creado | El servidor reconoció un recurso recién creado. Se ha creado un recurso (por ejemplo, un nuevo usuario o una nueva publicación de blog). |
| 202 | Aceptado | El servidor ha recibido la solicitud del cliente pero aún la está procesando. |
| 203 | Información no autorizada | La respuesta del servidor al cliente difiere de la respuesta inicial que envió el servidor. |
| 204 | Sin contenido | El servidor ha procesado la solicitud pero no devuelve ningún contenido. |
| 205 | Restablecer contenido | El cliente debe actualizar la muestra del documento. |
| 206 | Contenido parcial | El servidor está enviando sólo una parte del recurso. |
| 207 | Multi-Estado | La respuesta del servidor puede contener múltiples códigos de respuesta. |
| 208 | Ya reportado | La respuesta del servidor resalta el contenido interno duplicado con este código de estado. |
| 226 | Estoy usado | IM significa “manipulación de instancias” en la codificación Delta de HTTP . El servidor ha completado una solicitud GET y la respuesta del servidor incluye mensajes instantáneos. |
3XX – Redirección
Se utilizan para redirigir la solicitud del cliente a otro recurso, ya sea a otra página web o a un sitio web completamente distinto. Cuando encuentre un código de estado 3XX, el servidor lo redirigirá a una ubicación web diferente de su URI inicial.
| CÓDIGO | SIGNIFICADO | DESCRIPCIÓN |
| 300 | Múltiples opciones | El cliente debe elegir entre varias respuestas posibles para la solicitud del servidor. |
| 301 | Movido permanentemente | El servidor le dice al cliente que el recurso solicitado ahora está en otra URI de forma permanente y el cliente debe usar la nueva URL para todas las solicitudes futuras. |
| 302 | Encontró | El servidor le dice al cliente que el recurso solicitado está temporalmente en otra URI. Este código se usa comúnmente para redirecciones temporales, pero a menudo es mejor usar 303 o 307 |
| 303 | Ver otros | El servidor no redirige al cliente al recurso solicitado sino a otra página. |
| 304 | No modificado | La respuesta del servidor es la misma que en el pasado, por lo que el cliente puede seguir usando la versión en caché de la respuesta del servidor. |
| 305 | Usar Proxy (en desuso) | El cliente solo podía acceder al recurso solicitado a través de un proxy proporcionado en la respuesta. La descontinuación se debió a que la configuración en banda de un proxy no es segura. |
| 306 | (sin usar/reservado) | Una versión anterior de la especificación HTTP/1.1 utilizaba este código de respuesta. |
| 307 | Redirección temporal | El servidor le indica al cliente que el recurso que está buscando se encuentra temporalmente en otra URI. A diferencia de 302, el cliente debe acceder a la nueva URI utilizando el mismo método HTTP que la URI original. |
| 308 | Redirección permanente | El servidor le informa al cliente que el recurso que está buscando ahora se encuentra en otra URI de forma permanente. A diferencia de 301, el cliente debe acceder a la nueva URI utilizando el mismo método HTTP que la URI original. |
301 Moved Permanently
La imagen ilustra perfectamente cómo funcionan las redirecciones HTTP, concretamente con el código 301 Moved Permanently. En el ejemplo, el navegador solicita un recurso (GET /dog.png) al servidor examplecat.com. El servidor responde con un código 301, que significa “movido permanentemente”, junto con un encabezado Location: /cat.png, indicando la nueva ubicación del recurso. El navegador interpreta esta respuesta y automáticamente envía una nueva solicitud GET /cat.png. Esta vez, el servidor devuelve una respuesta 200 OK, indicando que el recurso se ha encontrado correctamente y enviando el contenido solicitado.
El código 301 es uno de los más comunes dentro de la categoría 3xx (redirecciones). Sirve para informar al cliente de que un recurso ha cambiado de dirección de forma permanente, de modo que los navegadores y los motores de búsqueda actualicen sus referencias. Existen otros códigos similares, como 302 Found (redirección temporal), 307 Temporary Redirect y 308 Permanent Redirect, cada uno con diferencias sutiles en cómo se manejan los métodos HTTP o la persistencia de la redirección.
Desde el punto de vista del pentesting y la seguridad web, las redirecciones son un punto interesante de análisis. Pueden utilizarse de manera legítima, pero también pueden ser manipuladas para generar vulnerabilidades como Open Redirects, donde un atacante redirige a un dominio externo malicioso. Además, al observar la secuencia de redirecciones, un analista puede descubrir rutas internas, subdominios o comportamientos del servidor que revelan parte de su estructura interna.
En resumen, el código 301 Moved Permanently le indica al cliente que el recurso ha cambiado de ubicación de forma definitiva. Esta mecánica no solo mejora la experiencia de navegación y el SEO, sino que también es un componente que los pentesters deben revisar cuidadosamente para detectar configuraciones incorrectas o redirecciones abiertas que puedan ser aprovechadas por un atacante.
4XX – Errores del cliente
Se utiliza para informar al cliente de que hubo un error con su solicitud. Se trata de errores del cliente, como una página faltante, un formato de datos incorrecto, un acceso no autorizado o un error en la solicitud.
| CÓDIGO | SIGNIFICADO | DESCRIPCIÓN |
| 400 | Solicitud incorrecta | El cliente ha enviado una solicitud con datos incompletos, mal construidos o no válidos. El servidor no puede procesar la solicitud debido a un error del cliente (por ejemplo, sintaxis de solicitud incorrecta). |
| 401 | No autorizado | El cliente no tiene la autorización necesaria para acceder al recurso solicitado. Se requiere autenticación y el cliente debe proporcionar credenciales válidas para acceder al recurso solicitado. |
| 402 | pago requerido | Un código de estado poco común reservado para los sistemas de pago digitales. |
| 403 | Prohibido | El servidor prohíbe al cliente acceder al recurso. El servidor entendió la solicitud, pero el cliente no tiene permiso para acceder al recurso solicitado. El servidor niega al cliente el acceso a un recurso. Tengo tendencia a desafiar este código de estado: Al abrir la fuente de fotogramas de algunos vídeos incrustados en una nueva pestaña, aparece este error, ya que los vídeos tienen una estricta política de origen idéntico. Sin embargo, (y paso el dato) a veces puedo descargar esos vídeos desde URL de fuentes alternativas que se encuentran a través del Inspector del navegador. |
| 404 | No encontrado | Este código denota un recurso inexistente en un servidor en funcionamiento. |
| 405 | Método no permitido | El servidor ha recibido y reconocido la solicitud, pero ha rechazado el método de solicitud específico. El recurso no permite esta solicitud de método, por ejemplo, envía una solicitud GET al recurso /create-account cuando esperaba una solicitud POST en su lugar. |
| 406 | Inaceptable | El sitio web o la aplicación web no admite la solicitud del cliente con un protocolo particular. |
| 407 | Se requiere autenticación proxy | Similar a 401 No autorizado , pero el servidor requiere autorización a través de un proxy. |
| 408 | Pide tiempo fuera | La solicitud que el cliente envió al servidor ha expirado. |
| 409 | Conflicto | La solicitud transmitida entra en conflicto con las operaciones internas del servidor. |
| 410 | Desaparecido | El recurso buscado por el cliente no está disponible permanentemente. |
| 411 | Longitud requerida | El servidor requiere el Content-Lengthcampo de encabezado, pero faltaba en la solicitud, por lo que el servidor lo rechazó. |
| 412 | Condición previa Falló | El servidor no cumple las condiciones indicadas por el cliente. |
| 413 | Carga útil demasiado grande | La entidad solicitada excede los límites del servidor. |
| 414 | URI demasiado larga | La URI solicitada por el cliente es más larga de lo que el servidor está dispuesto a interpretar. |
| 415 | Tipo de medio no compatible | El servidor no admite el formato multimedia de los datos solicitados y, por lo tanto, rechaza la solicitud. |
| 416 | Rango solicitado no satisfactorio | La respuesta del servidor no puede cumplir con el rango especificado por el Range campo de encabezado en la solicitud. |
| 417 | Expectativa fallida | El servidor no puede cumplir con la expectativa indicada por el Expect campo de encabezado de la solicitud. |
| 418 | Soy una tetera | El servidor envía esta respuesta a solicitudes no deseadas, como consultas automatizadas. |
| 421 | Solicitud mal dirigida | La solicitud fue a un servidor incapaz de producir una respuesta. |
| 422 | Entidad no procesable | Los errores semánticos en la solicitud impidieron que el servidor enviara la respuesta esperada. |
| 423 | Bloqueado | El recurso solicitado está bloqueado. |
| 424 | Dependencia fallida | El fracaso de una solicitud anterior condenó a esta solicitud al fracaso. |
| 425 | Demasiado temprano | El servidor canceló una solicitud que podría ser parte de un ataque de repetición (intencional o no). |
| 426 | Se requiere actualización | El servidor solo ejecutará la solicitud después de que el cliente actualice a uno o más protocolos diferentes especificados en su Upgrade encabezado en una respuesta 426 . |
| 428 | Condición previa requerida | El servidor de origen requiere que la solicitud cumpla ciertas condiciones. |
| 429 | Demasiadas solicitudes | El cliente ha enviado demasiadas solicitudes en un período de tiempo determinado. |
| 431 | Los campos del encabezado de solicitud son demasiado grandes | El servidor no está dispuesto a procesar la solicitud debido a que los campos de encabezado son demasiado grandes. |
| 451 | No disponible por razones legales | El servidor no puede proporcionar legalmente el recurso solicitado, como una página censurada por el gobierno. |
404 Not Found
La imagen explica de manera muy simple el concepto de código de estado HTTP (status code). Muestra a la izquierda un navegador enviando una solicitud (GET /cat.png) al servidor y, en respuesta, el servidor devuelve un mensaje con el código 404 Not Found, indicando que el recurso solicitado —en este caso, la imagen cat.png— no existe o no puede ser localizado.
En este ejemplo, el 404 representa uno de los códigos más conocidos: el servidor está funcionando, pero no pudo encontrar el recurso solicitado. En el contexto de pentesting y hacking ético, estos códigos son muy útiles durante la fase de reconocimiento y enumeración, ya que permiten identificar rutas válidas, recursos ocultos o errores de configuración. Por ejemplo, un 403 Forbidden puede indicar la existencia de un archivo restringido, y un 500 Internal Server Error puede revelar fallos internos del servidor o de la aplicación.
La imagen muestra una página de error HTTP 404 generada por el servidor Apache Tomcat versión 8.5.6, lo que indica que el recurso solicitado (/pages/xx.jsp) no se encuentra disponible. Este tipo de respuesta se conoce como «Status report», una página de error por defecto que Tomcat muestra cuando no puede localizar un archivo o endpoint en la aplicación web.
En la parte superior se ve la línea HTTP Status 404 – /pages/xx.jsp, que especifica el código de estado (404 Not Found) y la ruta del recurso inexistente. Luego se incluyen tres campos descriptivos:
- type: “Status report”, que indica que es un mensaje de error generado automáticamente por el servidor.
- message: el recurso solicitado (/pages/xx.jsp).
- description: una breve explicación del error (“The requested resource is not available”).
Finalmente, en la parte inferior aparece la firma del servidor: Apache Tomcat/8.5.6, que revela tanto la tecnología utilizada como su versión exacta.
Desde una perspectiva de seguridad y pentesting, esta información es muy valiosa. El hecho de que el servidor muestre su versión en una respuesta de error es un riesgo de información expuesta, ya que permite a un atacante o auditor identificar el software y la versión exacta del entorno. Con esa información, se pueden buscar vulnerabilidades conocidas (por ejemplo, exploits públicos o CVEs asociados a Tomcat 8.5.6). Además, el hecho de que el error muestre la estructura de rutas internas (/pages/) puede ayudar a inferir la organización del proyecto o el framework utilizado (en este caso, probablemente una aplicación Java con JSP).
En un entorno seguro, este tipo de errores debería personalizarse para no revelar detalles del servidor ni su versión, devolviendo solo un mensaje genérico. Dejar las páginas de error por defecto de Tomcat, Apache, Nginx u otros servidores es una práctica común en entornos de desarrollo, pero en producción representa una fuga de información que puede facilitar el reconocimiento a un atacante.
En resumen, la imagen muestra un error 404 estándar de Apache Tomcat, que además de indicar un recurso inexistente, deja visible la versión del servidor, un detalle que en pruebas de pentesting se considera información sensible y que debería ocultarse mediante configuración o mediante páginas de error personalizadas.
5XX – Errores del servidor:
Se trata de errores del servidor. El cliente ha realizado una solicitud válida, pero el servidor no puede proporcionar el recurso solicitado. Esto está reservado para errores que ocurren en el lado del servidor y generalmente indican un problema bastante importante con el servidor que maneja la solicitud.
| CÓDIGO | SIGNIFICADO | DESCRIPCIÓN |
| 500 | Error Interno del Servidor | El servidor ha tenido problemas al procesar la solicitud del cliente. |
| 501 | No se ha implementado | El servidor no puede resolver el método de solicitud HTTP del cliente. |
| 502 | Puerta de enlace defectuosa | El servidor, que actúa como puerta de enlace o proxy, recibió un mensaje no válido de un servidor entrante. |
| 503 | Servicio No Disponible | El servidor parece no funcionar y no puede procesar la solicitud del cliente. Este servidor no puede manejar su solicitud porque está sobrecargado o inactivo por mantenimiento. El servidor no está funcionando y no puede responder a ninguna solicitud que le hagas. Los visitantes del sitio web están a merced de los administradores |
| 504 | Tiempo de espera de la puerta de enlace | El servidor, que actúa como puerta de enlace, no logra producir una respuesta a tiempo. |
| 505 | Versión HTTP no compatible | El servidor no admite la versión HTTP utilizada en la solicitud. |
| 506 | La variante también negocia | El servidor tiene un error de configuración interna que genera conflictos de contenido. |
| 507 | Espacio insuficiente | El servidor no tiene suficiente almacenamiento para ejecutar el método HTTP de la solicitud. |
| 508 | Bucle detectado | El servidor detectó un bucle infinito mientras procesaba la solicitud. |
| 510 | No extendido | El servidor requiere más extensiones a la solicitud antes de cumplirla. |
| 511 | Se requiere autenticación de red | El cliente debe autenticarse en la red para acceder al recurso. |
Esta hoja de trucos sobre códigos de estado HTTP cubre todos los códigos HTTP. Te recomiendo consultar un excelente recurso http.cat para estudiar los códigos de estado. Todos los códigos de estado HTTP tienen tres dígitos. Si ves un código de error de cuatro dígitos, es diferente: es un tipo de error del sitio de CloudFlare. Es muy importante también entender los tipos de errores que nos devuelve el navegador, muchas veces un atacante a partir de forzar un error, puede encontrar información que les sea útil, por ejemplo para visualizar que tipo de aplicación y versión utiliza, de esa manera lo único que tiene que realizar es buscar el EXPLOIT correspondiente.
Resumen del artículo (para facilitar su comprensión)
- Qué es una respuesta HTTP: es el mensaje que el servidor envía tras recibir y procesar la petición: consta de status-line, headers, una línea vacía \r\n y el body opcional con el contenido (HTML, JSON, imagen, etc.).
- Status-line (línea de estado): HTTP/1.1 200 OK — contiene versión del protocolo, código numérico (1xx–5xx) y texto descriptivo. Categorías útiles para pentesting:
- 2xx éxito (200, 201)
- 3xx redirecciones (301, 302, 307, 308) — revisar open redirects y secuencias de redirección
- 4xx errores del cliente (401, 403, 404, 429) — útiles para enumeración y control de acceso
- 5xx errores de servidor (500, 502, 503) — pueden filtrar info sensible o indicar fallos explotables
- Encabezados de respuesta clave y su relevancia:
- Content-Type — tipo MIME; mal uso puede producir MIME sniffing y XSS.
- Content-Length / Transfer-Encoding — delimitan el body; inconsistencias pueden facilitar request/response smuggling.
- Cache-Control, ETag, Vary, Age — políticas de caché; malas configuraciones permiten cache poisoning o fuga de información.
- Set-Cookie — revisar flags HttpOnly, Secure, SameSite; su falta facilita robo de sesión o CSRF.
- Strict-Transport-Security (HSTS) — indica forzado HTTPS; su ausencia es un hallazgo.
- Content-Security-Policy (CSP), X-Frame-Options, X-Content-Type-Options — mitigaciones importantes; verificar presencia y calidad.
- Server, X-Powered-By — fingerprinting; exponer versiones puede facilitar búsqueda de CVEs.
- Location (en 3xx) — revisar redirecciones abiertas.
- Body de la respuesta: contiene datos reales. Inspeccionar por datos sensibles (tokens, rutas internas, credenciales olvidadas, stack traces) y por reflejos inseguros (riesgo XSS).
- Errores y páginas por defecto: páginas de error que muestran stack traces, rutas internas o versiones (ej. Tomcat/8.x) son fugas de información críticas para reconocimiento.
- Prácticas de análisis: usar un proxy (Burp/ZAP) para interceptar y comparar HEAD vs GET, forzar conditional requests (If-None-Match, If-Modified-Since), probar variaciones de Accept/Accept-Encoding y revisar headers de seguridad y cookies.
- Códigos de estado útiles para pruebas: aprende a interpretar 200/201, 3xx, 401/403/404, 4xx en general y 5xx; cada respuesta sugiere una investigación distinta (autorización, existencia de recurso, errores internos).
Recomendaciones prácticas (rápidas)
- Inspecciona siempre las headers antes que el body: suelen dar más pistas.
- Si ves Server o X-Powered-By, considera que hay fingerprinting: anota versión y busca CVEs en entorno controlado.
- Páginas de error por defecto → personalizar en producción; como pentester, explótalas para obtener información durante el reconocimiento (solo con autorización).
- Verifica Set-Cookie flags y prueba la ausencia de Secure/HttpOnly/SameSite.
- Comprueba coherencia entre HEAD y GET y diferencias entre respuestas a distintos Accept/Accept-Encoding.
- Revisa redirecciones en Location por posibles open redirects.
- Comprueba cabeceras de seguridad (CSP, HSTS, X-Frame-Options, X-Content-Type-Options) y valora su configuración como hallazgo si faltan o son débiles.
10 preguntas basadas en el artículo
- ¿Qué elementos componen una solicitud (HTTP Request) y una respuesta (HTTP Response)?
- ¿Cuál es la diferencia entre los métodos HTTP GET y POST?
- ¿Qué función cumple la línea de estado en una respuesta HTTP?
- ¿Por qué es importante el encabezado Content-Type en una respuesta HTTP?
- ¿Qué información se puede obtener del encabezado Server y por qué puede representar un riesgo?
- ¿Qué tipo de vulnerabilidades pueden detectarse manipulando los encabezados HTTP?
- ¿Cuál es la diferencia entre los códigos de estado 4xx y 5xx?
- ¿Qué significa que un método HTTP sea “idempotente”? ¿Puedes dar un ejemplo?
- ¿Qué papel juega HTTPS en la seguridad de la comunicación cliente-servidor?
- ¿Por qué se recomienda personalizar las páginas de error HTTP (como las de código 404 o 500)?
Respuestas completas a las 10 preguntas
1. ¿Qué elementos componen una solicitud (HTTP Request) y una respuesta (HTTP Response)?
Una solicitud HTTP incluye:
- Línea de inicio: con el método, la ruta y la versión del protocolo.
- Encabezados: información adicional (como Host, User-Agent, etc.).
- Línea vacía: separa los encabezados del cuerpo.
- Cuerpo (opcional): datos enviados, como formularios o JSON.
Una respuesta HTTP incluye:
- Línea de estado: versión del protocolo + código de estado + mensaje.
- Encabezados: metadata de la respuesta (Content-Type, Server, etc.).
- Línea vacía.
- Cuerpo: contenido solicitado, como HTML, JSON o imágenes.
2. ¿Cuál es la diferencia entre los métodos HTTP GET y POST?
- GET solicita un recurso sin modificar nada. No lleva cuerpo y es seguro/idempotente.
- POST envía datos al servidor (como formularios) y puede modificar o crear recursos. No es idempotente.
3. ¿Qué función cumple la línea de estado en una respuesta HTTP?
La línea de estado indica:
- La versión del protocolo (por ejemplo HTTP/1.1).
- El código de estado (como 200, 404, 500).
- El mensaje textual (OK, Not Found, Internal Server Error).
Esta línea permite al cliente interpretar el resultado de la solicitud.
4. ¿Por qué es importante el encabezado Content-Type en una respuesta HTTP?
Porque indica el tipo de contenido que el servidor está devolviendo (HTML, JSON, imagen, etc.) y cómo debe interpretarlo el navegador. Un Content-Type mal configurado puede permitir ataques como XSS o content sniffing.
5. ¿Qué información se puede obtener del encabezado Server y por qué puede representar un riesgo?
El encabezado Server revela el software del servidor (como Apache, Nginx, Tomcat) e incluso la versión utilizada. Esto puede facilitar que un atacante identifique vulnerabilidades conocidas y busque exploits específicos.
6. ¿Qué tipo de vulnerabilidades pueden detectarse manipulando los encabezados HTTP?
- Host Header Injection: si el servidor confía en el encabezado Host.
- Cache Poisoning: usando Accept-Encoding o ETag.
- XSS: si el contenido no se escapa correctamente y se interpreta como HTML.
- CSRF: si no hay protección y se puede explotar vía cookies o redirecciones.
- Request Smuggling: manipulando Content-Length o Transfer-Encoding.
7. ¿Cuál es la diferencia entre los códigos de estado 4xx y 5xx?
- 4xx indica errores del cliente (por ejemplo, 404 recurso no encontrado, 403 acceso prohibido).
- 5xx indica errores del servidor (por ejemplo, 500 error interno, 503 servicio no disponible).
8. ¿Qué significa que un método HTTP sea “idempotente”? ¿Puedes dar un ejemplo?
Un método es idempotente si su resultado no cambia al repetirlo varias veces. Ejemplo:
- GET es idempotente: pedir una imagen dos veces no la cambia.
- DELETE también es idempotente: borrar un recurso ya eliminado no lo borra de nuevo.
9. ¿Qué papel juega HTTPS en la seguridad de la comunicación cliente-servidor?
HTTPS cifra la información entre cliente y servidor mediante SSL/TLS, evitando que pueda ser interceptada por atacantes. Protege datos sensibles como contraseñas, cookies, etc.
10. ¿Por qué se recomienda personalizar las páginas de error HTTP (como las de código 404 o 500)?
Porque las páginas por defecto pueden revelar:
- Tecnología y versión del servidor (ej: Tomcat/8.5.6).
- Estructura interna de rutas.
- Mensajes de error con información sensible.
Personalizarlas evita fugas de información que pueden ser útiles para un atacante.
10 ejercicios prácticos basados en el artículo
- Escribe una solicitud HTTP GET completa al recurso /login del dominio example.com, usando HTTP/1.1.
- Dado el siguiente código de estado 403, explica qué ocurrió y cómo puede afectar a un pentester.
- Simula una petición POST al endpoint /add_user con un JSON en el cuerpo. Indica los headers necesarios.
- Observa la siguiente línea: HTTP/1.1 500 Internal Server Error. ¿Qué indica y cómo se puede aprovechar en una auditoría?
- ¿Qué diferencia hay entre las respuestas 301 Moved Permanently y 302 Found?
- Modifica un encabezado Host en una petición para simular un ataque de Host Header Injection.
- Dado un encabezado Set-Cookie, escribe cómo se vería incluyendo las flags HttpOnly y Secure.
- Crea una solicitud HEAD para comprobar si existe el recurso /img/logo.png sin descargar el archivo.
- Lista al menos 3 encabezados de seguridad que debe revisar un pentester en una respuesta HTTP.
- Explica con tus propias palabras por qué el método CONNECT puede representar un riesgo de evasión de filtros.
Respuestas detalladas a los ejercicios
1. Solicitud GET completa:
GET /login HTTP/1.1
Host: example.com
User-Agent: curl/7.68.0
Accept: */*
2. Código 403 – Prohibido:
Significa que el recurso existe, pero el cliente no tiene permisos para acceder. Un pentester puede deducir que el recurso está protegido y buscar formas de saltarse las restricciones (por ejemplo, probando otras credenciales o roles).
3. Petición POST simulada:
POST /add_user HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 32
{
«username»: «admin»,
«pass»: «1234»
}
4. Código 500 – Error Interno del Servidor:
Indica un fallo en la lógica o configuración del backend. En pentesting, se puede intentar provocar errores 500 para extraer trazas, excepciones o información interna sensible.
5. Diferencia 301 vs 302:
- 301: redirección permanente. El navegador la guarda.
- 302: redirección temporal. El navegador no guarda la nueva URL.
6. Modificación del encabezado Host:
GET /reset HTTP/1.1
Host: attacker.com
Esto puede provocar que el servidor construya URLs con un dominio controlado por el atacante.
7. Encabezado Set-Cookie seguro:
Set-Cookie: sessionId=abc123; HttpOnly; Secure
Evita que el JavaScript acceda a la cookie y que se envíe por HTTP sin cifrado.
8. Solicitud HEAD para verificar archivo:
HEAD /img/logo.png HTTP/1.1
Host: example.com
9. Tres encabezados de seguridad importantes:
- Strict-Transport-Security
- X-Frame-Options
- Content-Security-Policy
10. Riesgo del método CONNECT:
Permite crear túneles cifrados a través de proxies. Si no está bien controlado, puede usarse para evadir firewalls o para acceder a servidores internos de forma indirecta.
Despedida — qué aprendiste y cómo te servirá
Has aprendido a leer y analizar respuestas HTTP con ojos de pentester: qué te dice la status-line, qué información aportan los headers, por qué el body puede contener secretos y cómo las combinaciones (headers + body + códigos) revelan vectores de ataque o mala configuración. Esto te convierte en alguien capaz de: detectar fugas de información, identificar malos manejos de caché, localizar redirecciones peligrosas, evaluar configuraciones de cookies y comprobar la presencia y calidad de cabeceras de seguridad —todo lo necesario para realizar hallazgos reproducibles y formular recomendaciones de mitigación.