3. HTTP, métodos, cabeceras, códigos de estado y riesgos asociados

3.1 Introducción

REST se construye sobre HTTP. Eso significa que la seguridad de una API no depende solo de sus reglas de negocio, sino también de cómo usa el protocolo subyacente. Un mal uso de métodos, cabeceras o códigos de estado puede abrir la puerta a bypass de controles, filtración de información, cacheo indebido o comportamientos inesperados en clientes y proxies.

Con frecuencia, los problemas no aparecen porque HTTP sea inseguro, sino porque la API utiliza el protocolo de manera inconsistente. Por ejemplo, endpoints que cambian estado con `GET`, respuestas sensibles marcadas como cacheables o errores que revelan demasiado detalle técnico.

Por eso, este tema estudia HTTP desde una perspectiva de seguridad aplicada a APIs REST.

3.2 HTTP como contrato operativo

HTTP no es solo un canal de transporte. Define una semántica de interacción entre cliente y servidor: cómo se representa un recurso, qué intención expresa cada método, qué metadatos acompañan la solicitud y cómo debe interpretarse el resultado.

Cuando la API respeta esa semántica, es más fácil aplicar controles y razonar sobre riesgos. Cuando la rompe, aparecen ambigüedades que afectan autenticación, autorización, cacheo, monitoreo y auditoría.

3.3 Estructura básica de una solicitud HTTP

Una solicitud HTTP suele incluir varios elementos, y todos pueden tener relevancia de seguridad:

• Método: expresa la intención general de la operación.
• URL y path: identifican el recurso o endpoint objetivo.
• Query string: agrega filtros, opciones o parámetros adicionales.
• Cabeceras: transportan metadatos como autenticación, tipo de contenido, origen o trazabilidad.
• Cuerpo: contiene datos de entrada, habitualmente en JSON.

Cada una de estas partes debe tratarse como entrada no confiable. Aunque algunas parezcan controladas por clientes “legítimos”, todas pueden ser manipuladas por un atacante.

3.4 Métodos HTTP y su semántica

Los métodos HTTP expresan la naturaleza general de la operación. En seguridad, respetar su semántica es clave para evitar acciones ocultas, controles inconsistentes y efectos secundarios inesperados.

3.5 Riesgos de usar mal GET

`GET` debería ser un método seguro en el sentido de no producir cambios de estado en el servidor. Si una API usa `GET` para activar acciones, enviar correos, confirmar operaciones o modificar datos, rompe esa expectativa y crea varios riesgos.

• Los crawlers o prefetchers podrían ejecutar acciones sin intención humana.
• Los proxies y navegadores podrían cachear respuestas sensibles.
• Los controles CSRF se vuelven más difíciles de razonar.
• Los sistemas de monitoreo pueden interpretar la operación como lectura inocua cuando no lo es.

En APIs seguras, `GET` debe utilizarse para consulta y recuperación, no para acciones con efectos colaterales.

3.6 POST, PUT y PATCH: diferencias que importan

Desde una mirada superficial, estos métodos parecen equivalentes porque todos “envían datos”. Pero desde seguridad, la diferencia importa mucho.

• POST suele utilizarse para creación o acciones no idempotentes. Requiere especial atención frente a replay, abuso masivo y duplicación de operaciones.
• PUT implica reemplazo completo del recurso. Si el cliente omite campos, puede borrar o resetear valores sin querer.
• PATCH modifica parcialmente. Si no se valida bien qué campos son editables, puede transformarse en una puerta para escalación de privilegios o alteración de estados internos.

3.7 DELETE y operaciones destructivas

`DELETE` expresa intención destructiva y por eso merece controles reforzados. No basta con verificar que el usuario esté autenticado; hay que validar si realmente tiene permiso para eliminar ese recurso en ese contexto.

También conviene considerar:

• Si la eliminación es lógica o física.
• Si existen dependencias sobre otros recursos.
• Si la operación requiere confirmación adicional o trazabilidad reforzada.
• Si la respuesta revela demasiada información cuando el recurso no existe o no pertenece al usuario.

3.8 Idempotencia y seguridad

La idempotencia indica que repetir la misma solicitud produce el mismo resultado observable. Es un concepto importante porque afecta retries, clientes distribuidos, proxies y resistencia ante fallos de red.

Desde seguridad, una operación no idempotente mal diseñada puede ser explotada mediante reenvíos intencionales, duplicación de solicitudes o automatización. Esto es especialmente relevante en pagos, altas de recursos, emisión de cupones o acciones administrativas.

Una arquitectura segura distingue claramente qué operaciones pueden repetirse sin daño y cuáles requieren controles contra replay, llaves de idempotencia o lógica de deduplicación.

3.9 Cabeceras HTTP relevantes para seguridad

Las cabeceras transportan metadatos críticos y muchas veces condicionan la forma en que la API autentica, interpreta y responde a una solicitud.

3.10 Authorization y manejo de credenciales

La cabecera `Authorization` suele contener uno de los activos más sensibles de la API: tokens Bearer, Basic Auth o esquemas personalizados. Un tratamiento incorrecto de esta cabecera puede exponer credenciales en logs, errores, trazas o herramientas de monitoreo.

Buenas prácticas básicas:

• No registrar su valor completo en logs.
• No reenviarla a servicios internos que no la necesitan.
• No confiar en esquemas personalizados mal documentados.
• Verificar expiración, firma, audiencia y contexto del token.

3.11 Content-Type, parsing y confusión de formatos

Una API debe saber exactamente qué formato de entrada acepta y cómo lo procesa. Si el `Content-Type` no se valida o el servidor intenta adivinar el formato, pueden aparecer ambigüedades y bypass de controles.

Ejemplos de problemas:

• El cliente envía un cuerpo inesperado y el backend lo interpreta parcialmente.
• Se aceptan múltiples formatos con reglas de validación inconsistentes.
• Un parser tolerante procesa campos no documentados o valores anómalos.
• La API cree que recibe JSON, pero una librería intermedia procesa otra cosa.

3.12 Query strings y exposición accidental

Los parámetros en la URL son útiles para filtros y paginación, pero presentan riesgos particulares. A diferencia del cuerpo, suelen quedar más expuestos en logs de servidores, proxies, herramientas de monitoreo, historiales de navegador y enlaces compartidos.

Por eso, no conviene enviar en query strings:

• Tokens o credenciales.
• Datos personales sensibles.
• Referencias internas que no deberían circular fuera de contexto.
• Instrucciones de depuración o comportamiento especial no gobernado.

3.13 Códigos de estado HTTP y su valor de seguridad

Los códigos de estado ayudan a clientes, gateways y sistemas de monitoreo a interpretar el resultado de una operación. Si se usan de forma incoherente, la API filtra información, confunde consumidores y dificulta respuesta ante incidentes.

3.14 401, 403 y 404: diferencias sensibles

Estos códigos suelen ser fuente de errores de diseño. Desde seguridad, la diferencia entre “no autenticado”, “no autorizado” y “no encontrado” puede tener impacto en enumeración de recursos y perfilado del sistema.

• 401 indica que falta autenticación o la credencial es inválida.
• 403 indica que la identidad es conocida pero no tiene permiso.
• 404 puede utilizarse estratégicamente para no confirmar la existencia de ciertos recursos.

No existe una única regla universal. Lo importante es que la política sea consistente y no revele información útil para un atacante.

3.15 Respuestas de error y fuga de información

Los mensajes de error suelen ser una fuente silenciosa de exposición. Un error demasiado detallado puede revelar nombres de tablas, rutas internas, formatos esperados, existencia de usuarios, estados de negocio o dependencias tecnológicas.

Una respuesta de error segura debería:

• Ser útil para el cliente legítimo sin exponer detalle interno innecesario.
• Mantener una estructura consistente.
• Incluir identificadores de correlación cuando haga falta soporte o auditoría.
• Reservar el detalle técnico profundo para logs internos protegidos.

3.16 Cache-Control y almacenamiento de respuestas

HTTP permite cachear respuestas para mejorar rendimiento, pero una mala política de cacheo puede exponer información sensible. Si una respuesta con datos privados se marca incorrectamente como pública o cacheable, otros usuarios, proxies o clientes compartidos podrían acceder a ella.

En APIs con datos sensibles, conviene revisar explícitamente:

• Cabeceras `Cache-Control` apropiadas.
• Uso o no de `ETag` y validación condicional.
• Separación entre contenido público y privado.
• Comportamiento de caches intermedias y CDNs.

3.17 Proxies, balanceadores y cabeceras de confianza

Muchas APIs operan detrás de reverse proxies, load balancers o API gateways. En esos entornos, parte de la información relevante llega por cabeceras agregadas por infraestructura intermedia, como IP original, protocolo o host efectivo.

El problema aparece cuando el backend confía ciegamente en cabeceras que también podrían ser enviadas por el cliente. Si la cadena de confianza no está bien definida, un atacante puede falsificar origen, saltar controles contextuales o alterar auditoría.

3.18 Riesgos frecuentes relacionados con HTTP

• Usar `GET` para operaciones que modifican estado.
• Aceptar métodos no necesarios o no documentados.
• Exponer tokens en query strings o logs.
• Devolver códigos de estado inconsistentes según el caso.
• Enviar detalles internos en respuestas 4xx o 5xx.
• No controlar `Content-Type` ni formatos admitidos.
• Confiar en cabeceras reenviadas sin validar la infraestructura.
• Permitir cacheo de respuestas sensibles.

3.19 Qué debes recordar de este tema

• HTTP forma parte del modelo de seguridad de una API, no solo de su transporte.
• Los métodos deben respetar su semántica para evitar efectos secundarios inseguros.
• Las cabeceras son metadatos críticos y muchas transportan información sensible.
• Los códigos de estado deben ser consistentes para no filtrar información ni confundir controles.
• Cacheo, parsing, proxies y errores son fuentes habituales de riesgo cuando HTTP se usa mal.

3.20 Conclusión

Diseñar una API segura requiere entender HTTP con precisión. Los métodos, cabeceras, códigos de estado y reglas de cacheo no son detalles menores: condicionan cómo interactúan los clientes, cómo se aplican los controles y cuánta información puede aprender un atacante observando el comportamiento del sistema.

En el próximo tema estudiaremos las amenazas comunes en APIs REST, como abuso, enumeración, exfiltración y automatización maliciosa, para ver cómo estos riesgos se manifiestan en escenarios reales.