HTTP como superficie de seguridad

01 // Lee el intercambio antes de interpretarlo

HTTP conecta solicitudes y respuestas. Una solicitud nombra un recurso, usa un método y puede llevar datos; una respuesta comunica un estado, headers y un cuerpo. En una revisión defensiva, anota primero lo observado y separa cualquier explicación que todavía sea hipótesis.

Ejemplo: un 500 intermitente dice que el servidor encontró un error. Conserva hora, ruta e identificador de solicitud para buscar su traza; el código aislado no demuestra una vulnerabilidad ni su causa.

02 // Revisa método, identidad y permiso

GET suele consultar; POST, PUT y DELETE suelen cambiar estado. El método describe una intención, no autoriza la operación. Pregunta si hace falta en esa ruta, qué identidad puede usarlo, qué permiso se verifica y qué registro deja.

Ejemplo: /preferencias en example.com puede aceptar cambios de una sesión válida. Aun así, el servidor debe comprobar que esa sesión puede modificar precisamente la preferencia solicitada.

03 // Trata estados y destinos como señales distintas

Los 4xx suelen indicar que la petición no pudo completarse como se envió; los 5xx, un error del servidor. Investiga con contexto y evita atribuir intención a partir del número. Si el error expone detalles internos, registra ese riesgo por separado.

Una redirección después del inicio de sesión debe terminar en un destino controlado por la aplicación. HTTPS protege el transporte, pero no decide si un sitio externo es apropiado. Usa rutas internas validadas o una lista pequeña de destinos permitidos.

04 // Pregunta quién puede recibir la copia

Una caché compartida puede reutilizar una respuesta para más de una persona. Antes de guardar contenido de cuenta, revisa su sensibilidad, quién comparte la caché y qué directivas impiden servir la copia a otra sesión. Reducir el tiempo de caché no resuelve por sí solo quién puede verla.