La seguridad web no empieza buscando una falla. Empieza entendiendo qué ocurre cuando alguien abre una página, envía un formulario o accede a un área autenticada. Una aplicación está formada por personas, navegador, red, servidor, datos y reglas de acceso. Cada transición entre estas partes es una decisión de seguridad.
Esta guía muestra cómo observar esas transiciones y por qué esta forma de mirar encuentra más problemas que memorizar nombres de vulnerabilidades.
Empieza por el recorrido de una solicitud
Cuando el navegador realiza una solicitud HTTP, envía un método, una dirección, encabezados y, en ocasiones, un cuerpo con datos. El servidor decide cómo tratarla y devuelve una respuesta.
Una solicitud real se parece a esta:
POST /api/pedidos/1042/cancelar HTTP/1.1
Host: loja.exemplo.com
Cookie: sessao=a1b2c3d4...
Content-Type: application/json
{"motivo": "desistencia"}Para estudiar con método, plantea cuatro preguntas sobre ella:
- ¿Quién puede enviar esta solicitud?
- ¿Qué datos contiene y cómo se validan?
- ¿Qué autorización se necesita para ejecutar la acción?
- ¿Qué aparece en la respuesta, los registros y el navegador?
Aplicado a la solicitud anterior: la cookie indica quién está autenticado, pero nada en ella garantiza que esa persona sea propietaria del pedido 1042. Si el servidor cancela el pedido solo por recibir una sesión válida, cambiar el número a 1043 cancela el pedido de otra persona.
Este es todo el razonamiento de la categoría más frecuente del OWASP Top 10 y llegaste a él sin memorizar ningún nombre, solo preguntando quién puede hacer qué.
Autenticación no es autorización
La autenticación responde «¿quién intenta entrar?». La autorización responde «¿qué puede hacer esa identidad?».
La confusión entre ambas origina buena parte de los problemas de acceso. Una persona puede estar perfectamente autenticada y aun así no tener permiso para ver datos de otro usuario, cambiar una configuración o ejecutar una acción administrativa.
Al revisar una funcionalidad, busca la comprobación de autorización cerca de la acción sensible, en el servidor. Dos señales de alerta:
- el permiso se comprueba solo al construir la pantalla, no al ejecutar la acción;
- la decisión utiliza un identificador procedente del cliente sin volver a comprobarlo.
Los botones invisibles no sustituyen una regla en el servidor. La interfaz oculta la opción; la solicitud sigue pudiendo enviarse manualmente.
Entiende el papel de la sesión
Después del inicio de sesión, la aplicación necesita reconocer a la persona en las siguientes solicitudes. Esto suele ocurrir mediante un identificador de sesión o token. Ese identificador es la sesión autenticada: quien lo posee actúa como esa persona.
Para quien desarrolla, lo mínimo:
| Protección | Qué evita |
|---|---|
| HTTPS en todo el tráfico | Captura del identificador en tránsito |
Cookie con HttpOnly | Lectura por código JavaScript de la página |
Cookie con Secure | Envío por una conexión sin cifrar |
Cookie con SameSite | Envío automático desde otro sitio |
| Nuevo identificador tras iniciar sesión | Fijación de sesión |
| Caducidad y cierre explícito | Sesión válida indefinidamente |
| Nueva autenticación en acciones críticas | Uso de una sesión olvidada abierta |
Cambiar el identificador justo después de iniciar sesión merece destacarse: de lo contrario, un identificador que el atacante haya logrado plantar antes sigue siendo válido cuando la víctima se autentica.
Para quien estudia, observa cómo mantiene el estado la aplicación en un entorno de formación, sin reutilizar las técnicas en sistemas de terceros.
Utiliza el OWASP Top 10 como mapa, no como lista ciega
El OWASP Top 10 reúne riesgos recurrentes de las aplicaciones web y es un excelente índice de estudio. La edición actual es la de 2025:
| Categoría | |
|---|---|
| A01 | Broken Access Control |
| A02 | Security Misconfiguration |
| A03 | Software Supply Chain Failures |
| A04 | Cryptographic Failures |
| A05 | Injection |
| A06 | Insecure Design |
| A07 | Authentication Failures |
| A08 | Software or Data Integrity Failures |
| A09 | Security Logging and Alerting Failures |
| A10 | Mishandling of Exceptional Conditions |
Dos observaciones útiles para quien empieza. La primera: las fallas de control de acceso encabezan la lista, y son la categoría que encuentra la pregunta «¿quién puede enviar esta solicitud?». La segunda: la lista no clasifica la gravedad para tu caso. Una misma categoría tiene impactos muy diferentes según los datos, la arquitectura y los controles existentes.
Elige un tema a la vez. Entiende qué propiedad de seguridad afecta, qué decisión de desarrollo lo reduce y cómo confirmaría un equipo la corrección. El objetivo es aprender a construir y revisar mejores sistemas, además de reconocer nombres de vulnerabilidades.
Plantea preguntas de arquitectura antes de probar
Dibuja el recorrido de una funcionalidad: navegador, ruta, servicio, base de datos y respuesta. En cada transición, pregunta qué datos son confiables, qué identidad actúa, qué autorización se comprueba y qué evidencia queda registrada.
La regla que organiza todo esto: un dato que cruzó la frontera del cliente no es confiable, por mucho que la interfaz lo haya validado. La validación en el navegador existe para la experiencia de la persona; la validación en el servidor existe para la seguridad. Parecen redundantes y no lo son: solo la segunda es obligatoria.
Conviene observar qué entró en la lista de 2025: las fallas de la cadena de suministro de software ocupan ahora la tercera posición. Para quien desarrolla, significa que la dependencia instalada forma parte de su superficie de ataque. Saber qué utiliza el proyecto, de dónde procede y con qué frecuencia se actualiza dejó de ser una tarea secundaria.
Para quien desarrolla, la seguridad también aparece en el ciclo de cambios: revisión de código, pruebas, actualización de dependencias, registros útiles y una forma de corregir rápidamente. Para quien estudia, el objetivo es entender los controles y validar hipótesis en aplicaciones educativas o propias.
Siguiente paso seguro
Monta un laboratorio local con una aplicación educativa deliberadamente vulnerable: OWASP WebGoat y Juice Shop existen precisamente para eso. Antes de empezar, documenta el objetivo, aísla la red y registra lo que esperas observar.
Un primer ejercicio concreto: abre las herramientas de desarrollo del navegador, utiliza cualquier funcionalidad de la aplicación de entrenamiento y observa la solicitud que genera. Después responde a las cuatro preguntas de la primera sección sobre ella. Es el ejercicio más económico que existe y enseña más que cualquier lista de comandos.
Después, compara esta guía con el artículo sobre laboratorio seguro y avanza hacia autenticación y protección de cuentas.
Estudia únicamente en aplicaciones propias, educativas o con autorización explícita. Encontrar un problema en un sistema de terceros no autoriza a probarlo: utiliza el canal de divulgación responsable de la organización.
