HTTP y proxies

Una página puede generar muchos intercambios HTTP: cargar una imagen, consultar una cesta o guardar una dirección. Leer una solicitud y su respuesta ayuda a explicar qué ocurrió. Por sí solo, eso no demuestra que la decisión de seguridad fuera correcta.

GET /catalog HTTP/1.11
Host: books.example2

HTTP/1.1 200 OK3
Content-Type: application/json4
{"items":3}5

La solicitud describe una operación

El método expresa la operación prevista. El destino identifica el recurso; las cabeceras llevan metadatos; algunas solicitudes incluyen un cuerpo. Las versiones de HTTP codifican estos elementos de forma distinta, pero conservan una semántica compartida.

GET se define como seguro: el cliente solicita recuperar información, no cambiar estado. Registrar esa consulta en un log es compatible con la definición. Un GET que elimina una cuenta incumple esa intención y crea riesgos por recuperaciones automáticas. Idempotencia significa que repetir una operación tiene el mismo efecto previsto que hacerla una vez; las respuestas y los registros pueden variar. Consulta la semántica HTTP.

El estado no cuenta toda la historia

Un código 2xx comunica éxito según su significado; no demuestra autorización correcta. Una respuesta HEAD exitosa no lleva cuerpo de contenido. Un 3xx tampoco siempre redirige: 304 se relaciona con la validación de caché.

401 indica credenciales de autenticación ausentes o inválidas; 403 expresa que el servidor rechaza la solicitud. Una aplicación puede usar 404 para ocultar la existencia de un recurso. Combina comportamiento documentado, cuerpo de respuesta y evidencia del servidor.

Las cookies transportan valores

Una cookie puede guardar una preferencia, un identificador de sesión u otro estado. Secure restringe su envío a canales seguros; HttpOnly impide leerla mediante las API de cookies de JavaScript; SameSite afecta su envío entre sitios. Domain y Path delimitan la entrega, pero Path no aísla de forma fiable aplicaciones distintas.

Estos atributos complementan la caducidad de sesión y la autorización. No establecen si el usuario puede leer un recibo concreto.

TLS y los proxies tienen funciones distintas

TLS protege la conexión frente a observación y modificación en la red cuando se validan correctamente los extremos y la confianza. No decide si un reembolso es legítimo. Un proxy directo sirve a clientes; uno inverso se sitúa delante de servicios. Un proxy de depuración solo inspecciona HTTPS cuando el cliente y el tráfico están configurados para usarlo y confiar en él. Algunas conexiones simplemente pasan por un túnel.

Solo proxies designados como confiables deben aportar información de reenvío relacionada con la identidad; la aplicación debe gestionar coherentemente los valores externos no confiables.

Escenario: el recibo que quedó guardado

Mina cierra sesión en una tableta compartida. La siguiente persona ve su recibo. Las posibles causas incluyen estado de aplicación, historial, caché local o caché compartida. El equipo identifica dónde quedó la información antes de elegir el control.

Guardar una respuesta autenticada en caché no es inseguro automáticamente: importan su sensibilidad y las reglas de uso compartido. CORS es otra frontera: regula el acceso del navegador a respuestas de otros orígenes. Fetch no permite compartir respuestas con credenciales mediante un origen comodín; el navegador rechaza esa combinación. La autorización del servidor sigue siendo necesaria.

Una nota útil identifica la operación, el permiso esperado, el resultado y el componente que aportó la evidencia.

Elige una política a partir de un requisito concreto

La tienda ficticia tiene dos requisitos. Las respuestas del catálogo público pueden reutilizarse durante sesenta segundos. Las cachés HTTP no deben almacenar recibos. Compara estas propuestas para los recibos:

Para el catálogo público no personalizado, public, max-age=60 permite almacenamiento compartido y sesenta segundos de vigencia, según las reglas de caché HTTP. Es la política de esta tienda, no una recomendación para todo catálogo. Solo la tercera propuesta para recibos cumple su requisito de no almacenamiento. Son directivas de respuesta sin argumentos de nombres de campos. Regulan cachés HTTP que respetan el protocolo; no son órdenes de borrado de capturas de pantalla, archivos exportados ni todo el almacenamiento gestionado por la aplicación.

Sigue también las conexiones. Supón que TLS termina en el proxy inverso de la tienda, que abre otra conexión con la aplicación. La validación del certificado por el navegador cubre la conexión entre navegador y proxy. El tramo entre proxy y aplicación necesita su propia protección documentada y validación del otro extremo. El candado no establece esa segunda configuración.

La nota de revisión debe distinguir tres afirmaciones: la directiva de caché elegida satisface un requisito, la copia observada procede de una capa de almacenamiento concreta y cada conexión tiene la protección prevista. La evidencia de una no establece las demás.