Tema 2
Comprender cómo se comunican navegador, servidor y aplicación es indispensable para entender por qué aparecen vulnerabilidades como XSS, CSRF, secuestro de sesión, exposición de cookies o controles de acceso defectuosos. La seguridad web comienza por entender el flujo técnico real de cada petición.
Cuando un usuario abre una aplicación web, hace clic en un enlace, envía un formulario o consume una API desde el navegador, ocurren varios intercambios entre componentes distintos. El usuario suele ver una experiencia simple, pero debajo existe una secuencia precisa de solicitudes, respuestas, procesamiento de datos, almacenamiento de estado y ejecución de código en distintos lugares.
Muchas fallas de seguridad aparecen porque no se comprende bien esa secuencia. Se valida en el navegador lo que debería validarse en el servidor, se confía en parámetros manipulables, se expone información en respuestas, se usan cookies sin protección adecuada o se construyen controles de acceso suponiendo cosas que el protocolo no garantiza.
Por eso este tema no es solo teórico. Entender HTTP, HTTPS, navegadores, servidores y el modelo cliente-servidor permite ver con claridad dónde están los límites de confianza y qué decisiones deben protegerse.
En una aplicación web típica, el navegador actúa como cliente y el servidor responde a sus solicitudes. El cliente pide recursos o ejecuta acciones; el servidor recibe datos, aplica lógica de negocio, consulta bases de datos y devuelve una respuesta.
Ese modelo parece simple, pero tiene una implicancia crítica para la seguridad: el cliente está del lado del usuario. Eso significa que no puede considerarse una zona confiable. Aunque la interfaz haya sido diseñada por el desarrollador, el usuario controla su dispositivo, su navegador y las peticiones que envía.
Desde el punto de vista de seguridad, la primera regla del modelo cliente-servidor es clara: el servidor debe asumir que toda solicitud puede ser manipulada.
Para entender dónde puede aparecer una falla, conviene separar los componentes básicos que intervienen en la comunicación.
La seguridad puede fallar en cualquiera de esos puntos o, más frecuentemente, en la relación entre ellos.
HTTP es el protocolo de comunicación que permite el intercambio de solicitudes y respuestas entre clientes y servidores web. Es la base sobre la que funcionan páginas, formularios, APIs y prácticamente toda interacción web moderna.
Cuando un usuario accede a una URL, el navegador construye una solicitud HTTP. Esa solicitud incluye un método, una ruta, cabeceras, a veces cookies y, en ciertos casos, un cuerpo con datos. El servidor recibe esa información, la procesa y devuelve una respuesta con un código de estado, cabeceras y un contenido.
Para seguridad, lo importante es entender que HTTP define cómo se intercambian mensajes, pero no garantiza por sí mismo que el contenido sea confiable, que el usuario sea quien dice ser o que la acción esté autorizada.
Una solicitud HTTP puede contener varios elementos relevantes para la seguridad:
Cualquiera de esos elementos puede ser manipulado. Un atacante puede cambiar parámetros, repetir peticiones, alterar cabeceras, falsificar cuerpos o automatizar miles de solicitudes.
El servidor también envía información relevante en la respuesta. Allí aparecen decisiones que impactan directamente en seguridad.
| Elemento | Función | Impacto en seguridad |
|---|---|---|
| Código de estado | Indica éxito, error, redirección o rechazo | Puede revelar comportamientos, existencia de recursos o errores internos |
| Cabeceras | Definen políticas y metadatos | Pueden reforzar o debilitar protección del navegador |
| Set-Cookie | Entrega cookies al cliente | Determina seguridad de sesión y alcance del token |
| Cuerpo | Devuelve HTML, JSON, archivos o mensajes | Puede exponer datos sensibles o reflejar entrada peligrosa |
Los métodos HTTP representan intenciones diferentes. Comprenderlas ayuda a diseñar mejor la aplicación y a reducir errores.
Desde la seguridad, usar métodos correctamente importa porque:
Una característica fundamental de HTTP es que, por diseño, cada solicitud es independiente. El protocolo no recuerda automáticamente quién hizo la petición anterior ni qué estaba haciendo el usuario.
Eso obliga a las aplicaciones a construir mecanismos propios para mantener contexto, por ejemplo sesiones, cookies, tokens o identificadores temporales. Allí aparece una enorme parte del trabajo de seguridad web: autenticar a un usuario, mantener su estado, validar su autorización y cerrar correctamente el contexto cuando ya no corresponde.
Las cookies son pequeños datos que el servidor envía al navegador y que este puede reenviar en solicitudes posteriores al mismo dominio según ciertas reglas. Su uso más habitual es mantener sesiones autenticadas, pero también pueden almacenar preferencias, identificadores o información de seguimiento.
Desde la seguridad, las cookies importan porque muchas veces contienen o referencian el contexto de sesión. Si una cookie es robada, reutilizada o enviada indebidamente, un atacante puede tomar control de la cuenta o actuar como el usuario.
Por eso es importante configurar atributos como:
Una sesión es la forma en que la aplicación mantiene continuidad entre solicitudes separadas. El usuario inicia sesión una vez, pero la aplicación necesita reconocerlo en cada petición posterior.
Existen distintos enfoques:
Sea cual sea el enfoque, hay preguntas críticas:
HTTPS es HTTP sobre TLS. Su función principal es proteger la comunicación entre cliente y servidor para que terceros no puedan observarla ni modificarla fácilmente durante el tránsito.
HTTPS aporta:
Sin embargo, HTTPS no corrige errores lógicos ni vulnerabilidades de aplicación. Una aplicación con SQL Injection, XSS o control de acceso roto seguirá siendo vulnerable aunque use HTTPS.
El navegador no solo muestra contenido. También ejecuta JavaScript, aplica políticas de origen, almacena cookies, caché y datos locales, procesa redirecciones, envía formularios y decide qué recursos se pueden cargar desde distintos contextos.
Esto lo convierte en un actor central de la seguridad web. Muchas defensas dependen parcialmente de su comportamiento: políticas de mismo origen, cabeceras de seguridad, restricciones de contenido y atributos de cookies.
También por eso muchas vulnerabilidades impactan directamente en el navegador, por ejemplo XSS, clickjacking, robo de sesión en el lado cliente o abuso de almacenamiento local.
La política del mismo origen es una regla del navegador que restringe cómo un documento o script cargado desde un origen puede interactuar con recursos de otro origen. Un origen combina esquema, host y puerto.
Esta política no elimina todos los riesgos, pero es una barrera básica para impedir que un sitio cualquiera lea directamente datos sensibles de otro sitio en el navegador del usuario.
Su importancia en seguridad es enorme porque explica por qué existen controles como CORS, `SameSite`, tokens CSRF y otras medidas relacionadas con interacciones entre sitios.
En la práctica, la petición del navegador rara vez llega directamente a la lógica de negocio sin capas intermedias. Puede pasar por un servidor web, un proxy inverso, un balanceador, una CDN o un gateway antes de alcanzar el backend.
Cada capa puede agregar valor o riesgo:
Si estas capas están mal configuradas, el backend puede tomar decisiones basadas en datos engañosos o exponer recursos de forma no prevista.
Conviene visualizar el flujo general de una interacción normal:
En cada uno de estos pasos puede aparecer una debilidad distinta.
Comprender la comunicación web ayuda a identificar en qué etapa se insertan los fallos más comunes.
| Etapa | Error frecuente | Ejemplo |
|---|---|---|
| Recepción de datos | Falta de validación | Parámetros manipulados o inyecciones |
| Identificación de usuario | Sesión débil | Cookie robada o token reutilizable |
| Autorización | Confianza excesiva en el cliente | Acceso a recursos ajenos cambiando un ID |
| Generación de respuesta | Salida insegura | XSS por reflejar contenido sin escape |
| Configuración del navegador | Cabeceras ausentes o débiles | Mayor exposición a clickjacking o ejecución indebida |
| Integración entre capas | Suposiciones incorrectas | Confiar en cabeceras agregadas por proxies sin validarlas |
Uno de los errores más comunes en desarrollo web es creer que algo es seguro porque el usuario no lo ve en pantalla. En realidad, muchos datos son manipulables aunque no estén visibles en la interfaz.
Por eso el servidor nunca debe basar una decisión de seguridad en la simple presencia de un dato del cliente sin validarlo y contextualizarlo.
Muchas aplicaciones actuales ya no responden solo con HTML renderizado en servidor. También exponen APIs que devuelven JSON y son consumidas por SPAs, aplicaciones móviles o integraciones externas.
Aunque el formato cambie, los principios siguen siendo los mismos:
En otras palabras, una API no elimina los problemas clásicos de seguridad web; solo cambia su forma.
Tomemos un flujo cotidiano. Un usuario ingresa correo y contraseña en un formulario. El navegador envía esos datos al servidor mediante `POST`. El backend valida credenciales, crea una sesión y responde con una cookie de sesión. Después, cada vez que el usuario navega por su panel, el navegador reenvía esa cookie.
En este flujo pueden aparecer varios riesgos:
Este ejemplo muestra por qué el conocimiento del flujo técnico es inseparable de la seguridad.
Comprender cómo funcionan HTTP, HTTPS, navegadores, servidores y sesiones permite ver la aplicación web como realmente opera y no solo como se presenta en pantalla. Ese cambio de perspectiva es decisivo para construir controles sólidos y para interpretar correctamente las vulnerabilidades más frecuentes.
En el próximo tema estudiaremos las principales amenazas web y el OWASP Top 10, aprovechando esta base técnica para entender mejor cómo y dónde se materializa cada riesgo.