1. Introducción a la seguridad web y a OWASP Top 10

1.1 Introducción

Las aplicaciones web forman parte del funcionamiento diario de empresas, organismos públicos, comercios, universidades y plataformas personales. Un sistema de ventas, una tienda online, una API móvil, un panel administrativo, un portal de clientes o una intranet son, en esencia, aplicaciones web o servicios web expuestos a usuarios internos o externos.

Esa exposición trae valor porque permite acceso remoto, automatización, integración y escalabilidad. Pero también introduce riesgo. Cada formulario, parámetro, cookie, archivo subido, encabezado HTTP, endpoint de API y flujo de autenticación puede transformarse en un punto de ataque si fue diseñado, implementado o configurado incorrectamente.

La seguridad web no consiste solamente en evitar que un atacante "hackee" una página. Su propósito real es preservar la confidencialidad de la información, la integridad de los procesos, la disponibilidad del servicio, la seguridad de las sesiones, la trazabilidad de las acciones y la confianza en el sistema.

En este primer tema construiremos el marco conceptual necesario para entender por qué existen vulnerabilidades web, cómo se originan, qué papel cumple OWASP Top 10 y por qué la seguridad debe pensarse desde el diseño y no solo como corrección posterior.

1.2 Qué es la seguridad web

La seguridad web es la disciplina que se ocupa de proteger aplicaciones y servicios accesibles mediante tecnologías web frente a accesos no autorizados, manipulación de datos, abuso de funcionalidad, exposición de información y fallas de disponibilidad.

En términos prácticos, la seguridad web busca responder preguntas como estas:

• ¿Quién puede acceder al sistema y cómo se verifica su identidad?
• ¿Qué puede hacer cada usuario autenticado o no autenticado?
• ¿Qué datos recibe la aplicación y cómo los valida?
• ¿Qué información se guarda, se procesa y se expone?
• ¿Cómo se protege la sesión del usuario?
• ¿Qué sucede si alguien intenta enviar entradas maliciosas o abusar de una función?
• ¿Qué evidencias quedan registradas para detectar e investigar incidentes?

1.3 Qué protege realmente la seguridad web

Una visión superficial podría hacer pensar que la seguridad web protege únicamente páginas HTML. En realidad protege activos mucho más amplios y valiosos.

Por eso una vulnerabilidad web no debe medirse solo por "si rompe o no la página". Muchas veces el mayor impacto está en el acceso indebido a información, el abuso de procesos internos o la pérdida de confianza sobre el sistema.

1.4 Aplicación web, sitio web y API: diferencias importantes

No todo lo web tiene el mismo nivel de riesgo ni la misma complejidad. Distinguir conceptos ayuda a entender mejor la superficie de ataque.

• Sitio web informativo: publica contenido y suele tener poca interacción. Aun así puede presentar fallas de configuración, exposición de archivos o inyección si incorpora formularios o paneles de gestión.
• Aplicación web: procesa lógica de negocio, autenticación, sesiones, permisos, formularios, cargas de archivos y operaciones persistentes. Su superficie de ataque es mayor.
• API web: expone endpoints para que otros sistemas o clientes consuman datos y ejecuten acciones. Los riesgos de autorización, validación, autenticación y exposición excesiva suelen ser especialmente relevantes.

Hoy es común que una misma solución combine frontend web, backend, API REST, autenticación con tokens, panel administrativo y servicios externos. Desde seguridad, eso significa múltiples capas de interacción y más puntos donde puede aparecer una debilidad.

1.5 Cómo funciona, en términos generales, una aplicación web

Para comprender las vulnerabilidades hay que entender primero el flujo normal de una aplicación web. Aunque los detalles cambien según la tecnología, el patrón general es bastante estable.

1. El navegador o cliente envía una solicitud HTTP o HTTPS al servidor.
2. La solicitud incluye método, ruta, parámetros, encabezados, cookies y a veces cuerpo con datos.
3. El servidor procesa esa entrada y la combina con lógica de negocio.
4. La aplicación consulta o modifica datos en una base de datos u otros servicios.
5. El sistema devuelve una respuesta con HTML, JSON, archivos, redirecciones o códigos de estado.
6. El navegador interpreta la respuesta y mantiene el estado mediante cookies, almacenamiento o tokens.

Las vulnerabilidades suelen aparecer cuando alguno de esos pasos confía demasiado en la entrada, expone demasiada información, aplica controles inconsistentes o asume que el usuario actuará siempre de forma legítima.

1.6 Por qué las aplicaciones web son un objetivo tan frecuente

Las aplicaciones web son atacadas con frecuencia por una razón simple: están expuestas, contienen datos y permiten ejecutar acciones valiosas. A diferencia de otros sistemas internos, una aplicación pública puede ser observada, probada y atacada desde cualquier lugar con una conexión a internet.

Además, ofrecen una combinación especialmente atractiva para un atacante:

• Interacción directa con usuarios y datos reales.
• Exposición constante al exterior.
• Amplia variedad de tecnologías y configuraciones.
• Errores habituales en autenticación, autorización y validación de entradas.
• Dependencias de terceros y componentes desactualizados.
• Integraciones con bases de datos, almacenamiento, correo, APIs y servicios cloud.

Desde el punto de vista del atacante, una sola debilidad puede abrir el camino a robo de cuentas, acceso a datos, movimientos laterales, fraude o ejecución de código.

1.7 Objetivos de protección en seguridad web

Los principios clásicos de seguridad siguen siendo válidos en aplicaciones web, pero se manifiestan de forma concreta en funcionalidades y flujos.

• Confidencialidad: impedir que información sensible sea vista por quien no corresponde.
• Integridad: evitar modificaciones no autorizadas de datos, transacciones o configuraciones.
• Disponibilidad: mantener la aplicación accesible y operativa.
• Autenticación: identificar correctamente a cada usuario o sistema.
• Autorización: asegurar que cada identidad solo acceda a lo permitido.
• Trazabilidad: registrar acciones relevantes para detectar y analizar incidentes.
• Resiliencia: contener errores o ataques sin comprometer toda la solución.

Cuando una aplicación falla en uno de estos objetivos, la consecuencia no siempre es visible de inmediato. Un sistema puede seguir "funcionando" mientras expone datos o permite acciones indebidas en silencio.

1.8 Qué es una vulnerabilidad web

Una vulnerabilidad web es una debilidad en el diseño, implementación, configuración o operación de una aplicación que puede ser aprovechada para generar un comportamiento no previsto o inseguro.

No todas las vulnerabilidades se parecen entre sí. Algunas permiten leer información, otras modificar datos, otras evadir controles y otras ejecutar código o tomar control del servidor. También existen fallas que no dependen de una "inyección" clásica, sino de errores de lógica o autorizaciones mal planteadas.

Es importante distinguir entre varios conceptos:

• Amenaza: aquello que puede causar daño, por ejemplo un atacante o un abuso intencional.
• Vulnerabilidad: la debilidad aprovechable del sistema.
• Explotación: la acción concreta de aprovechar esa debilidad.
• Impacto: la consecuencia producida si la explotación tiene éxito.
• Riesgo: la combinación entre probabilidad e impacto.

1.9 Cómo nacen las vulnerabilidades

Las vulnerabilidades rara vez aparecen por una única causa. En general surgen por decisiones acumuladas o por supuestos equivocados sobre cómo será usado el sistema.

Entre los orígenes más comunes se encuentran:

• Confiar en datos provenientes del cliente.
• No validar o sanear adecuadamente entradas.
• Aplicar controles de acceso solo en la interfaz y no en el servidor.
• Diseñar flujos de autenticación débiles o recuperaciones de cuenta inseguras.
• Utilizar bibliotecas vulnerables o fuera de soporte.
• Exponer mensajes de error, archivos, backups o configuraciones internas.
• No registrar eventos relevantes o no revisar alertas.
• No considerar abuso de lógica de negocio en etapas tempranas del diseño.

1.10 La superficie de ataque en aplicaciones web

La superficie de ataque es el conjunto de puntos por los que un usuario o sistema interactúa con la aplicación y, por lo tanto, el conjunto de lugares donde puede intentarse un abuso.

En una aplicación web moderna, esa superficie incluye:

• Formularios de login, registro, recuperación y cambio de contraseña.
• Campos de búsqueda, filtros, comentarios y parámetros de URL.
• Cookies, tokens y mecanismos de sesión.
• Endpoints de API y servicios internos expuestos.
• Subida y descarga de archivos.
• Paneles de administración y funciones privilegiadas.
• Integraciones con servicios externos, webhooks y proveedores.
• Configuración del servidor, cabeceras HTTP, CORS y componentes instalados.

Mientras más extensa y menos controlada sea esa superficie, mayores oportunidades habrá para errores y explotación.

1.11 Ataques frecuentes en el mundo web

Incluso antes de estudiar cada categoría de OWASP conviene reconocer algunos patrones de ataque comunes.

• Inyección: introducir datos maliciosos para alterar consultas, comandos o interpretaciones.
• Cross-Site Scripting: inyectar código ejecutable en el navegador de otra persona.
• Fallas de control de acceso: acceder a recursos o funciones no autorizadas.
• Robo o fijación de sesión: secuestrar el contexto autenticado de una víctima.
• Fuerza bruta y credential stuffing: intentar acceso masivo con credenciales robadas o adivinadas.
• Exposición de datos sensibles: obtener información por cifrado débil, respuestas excesivas o almacenamiento inseguro.
• SSRF: inducir al servidor a realizar solicitudes internas o a destinos no previstos.
• Subida maliciosa de archivos: cargar contenido peligroso o abusar del procesamiento del servidor.

No todos estos ataques dependen de "romper" el sistema. Muchos explotan comportamientos válidos pero mal restringidos.

1.12 Seguridad del cliente y seguridad del servidor

Las aplicaciones web tienen una particularidad central: parte del procesamiento ocurre del lado del cliente y parte del lado del servidor. Desde seguridad, eso obliga a entender muy bien qué decisiones pueden confiarse al navegador y cuáles no.

Regla general: el cliente nunca debe ser considerado confiable. El navegador, la aplicación móvil o cualquier consumidor de API puede ser manipulado, automatizado o reemplazado por herramientas como proxies, scripts y clientes personalizados.

Por eso los controles críticos deben aplicarse en el servidor:

• Validación y normalización de entradas.
• Autenticación y autorización.
• Protección de datos sensibles.
• Restricciones de negocio.
• Registro de eventos y monitoreo.

Las validaciones del lado cliente mejoran experiencia de uso, pero no reemplazan controles reales de seguridad.

1.13 Qué es OWASP

OWASP significa Open Worldwide Application Security Project. Es una comunidad abierta enfocada en mejorar la seguridad del software. Produce documentación, guías, herramientas, proyectos de referencia y materiales educativos ampliamente utilizados en la industria.

OWASP no es un fabricante ni un organismo regulador. Su valor reside en reunir conocimiento práctico y consensuado sobre riesgos, metodologías y buenas prácticas de desarrollo seguro.

Entre sus recursos más conocidos se encuentran:

• OWASP Top 10.
• OWASP ASVS.
• OWASP Testing Guide.
• OWASP Cheat Sheet Series.
• OWASP Juice Shop y otros proyectos de entrenamiento.

1.14 Qué es OWASP Top 10

OWASP Top 10 es una lista de las categorías de riesgos de seguridad más relevantes en aplicaciones web. No es un ranking exhaustivo de todas las vulnerabilidades existentes, sino una selección de áreas críticas que aparecen con frecuencia y generan impactos importantes.

Su objetivo principal es pedagógico y de concientización. Ayuda a desarrolladores, líderes técnicos, testers, auditores y responsables de negocio a entender qué tipos de fallas deben observarse con especial atención.

La edición actualmente más utilizada como referencia formativa es la de 2021, cuyas categorías son:

1. A01: Broken Access Control
2. A02: Cryptographic Failures
3. A03: Injection
4. A04: Insecure Design
5. A05: Security Misconfiguration
6. A06: Vulnerable and Outdated Components
7. A07: Identification and Authentication Failures
8. A08: Software and Data Integrity Failures
9. A09: Security Logging and Monitoring Failures
10. A10: Server-Side Request Forgery

1.15 Por qué OWASP Top 10 es tan importante

OWASP Top 10 se volvió un estándar de hecho porque traduce un problema complejo en una lista entendible, útil para capacitación, revisión de proyectos y conversaciones entre áreas técnicas y no técnicas.

Su importancia práctica se ve en varios niveles:

• Permite a equipos de desarrollo priorizar aprendizajes y controles.
• Sirve como marco de referencia para revisiones de seguridad iniciales.
• Ayuda a organizaciones a evaluar su madurez en desarrollo seguro.
• Facilita comunicar riesgos a responsables de producto, management y auditoría.
• Ofrece un lenguaje común entre testers, pentesters, desarrolladores y arquitectos.

Sin embargo, debe utilizarse con criterio. Una aplicación puede estar libre de fallas obvias del Top 10 y aun así sufrir problemas graves de negocio, privacidad, fraude o seguridad específica del dominio.

1.16 Resumen conceptual de las 10 categorías

Antes de estudiarlas una por una en el curso, conviene tener una visión global de lo que representa cada categoría.

1.17 OWASP Top 10 no cubre todo

Un error frecuente en equipos principiantes es creer que aprender el Top 10 equivale a conocer toda la seguridad web. No es así. El Top 10 es un marco introductorio excelente, pero no agota el problema.

Hay áreas que requieren atención adicional, por ejemplo:

• Seguridad específica de APIs.
• Errores de lógica de negocio.
• Fraude y abuso funcional.
• Privacidad y minimización de datos.
• Seguridad en DevSecOps y pipelines.
• Configuraciones cloud, secretos y gestión de identidades.
• Problemas particulares de frameworks y arquitecturas modernas.

Por eso el curso combinará OWASP Top 10 con otras vulnerabilidades web y con criterios más amplios de diseño y defensa.

1.18 Vulnerabilidades técnicas versus fallas de negocio

En seguridad web no todo se reduce a errores técnicos clásicos. Una aplicación puede estar libre de SQL Injection y aun así permitir fraudes o abusos severos si su lógica de negocio fue mal diseñada.

Ejemplos de fallas de negocio:

• Aplicar descuentos múltiples por un error en el flujo de compra.
• Permitir transferencias sin límites o sin confirmaciones adecuadas.
• Exponer acciones administrativas mediante rutas predecibles.
• Conceder privilegios por confiar en un parámetro manipulable.

Esto es clave porque introduce una idea central: la seguridad no es solo sanitizar entradas, sino entender cómo puede ser abusado el sistema en su propósito real.

1.19 El rol del diseño seguro

Corregir vulnerabilidades una vez que la aplicación ya fue implementada suele ser más costoso y menos eficaz que pensar la seguridad desde el inicio. El diseño seguro busca anticipar abuso, dependencias críticas, flujos peligrosos y decisiones arquitectónicas que podrían volverse inseguras.

Diseñar con enfoque de seguridad implica:

• Identificar activos sensibles y funciones críticas.
• Definir claramente roles y permisos.
• Modelar amenazas y casos de abuso.
• Reducir exposición innecesaria.
• Separar contextos de confianza.
• Elegir mecanismos robustos para sesiones, cifrado y secretos.
• Planificar registro, monitoreo y respuesta.

Esto no elimina todos los errores, pero reduce la probabilidad de fallas estructurales difíciles de corregir más adelante.

1.20 Seguridad durante todo el ciclo de vida

Una aplicación no se vuelve segura por una única revisión final. La seguridad debe estar presente durante todo el ciclo de vida del software.

1.21 Errores frecuentes al comenzar a estudiar seguridad web

• Creer que seguridad web es solo aprender ataques famosos.
• Pensar que si una aplicación usa HTTPS ya está razonablemente protegida.
• Confiar en validaciones JavaScript como si fueran controles de seguridad reales.
• Asumir que estar autenticado equivale a estar autorizado.
• Reducir la seguridad a una herramienta de escaneo automático.
• Ignorar la lógica de negocio por enfocarse solo en payloads técnicos.
• Considerar OWASP Top 10 como una lista cerrada y suficiente para todo contexto.

1.22 Ejemplos concretos para entender el problema

Algunos ejemplos simples ayudan a conectar teoría con situaciones reales:

• Un usuario cambia manualmente el identificador de una URL y ve datos de otra persona: problema de control de acceso.
• Un formulario concatena directamente un parámetro en una consulta SQL: riesgo de inyección.
• Una API devuelve más campos de los necesarios, incluyendo información interna: exposición de datos.
• Una aplicación permite múltiples intentos de login sin controles: riesgo de fuerza bruta.
• El servidor acepta subir archivos sin validar tipo ni contenido: riesgo de ejecución o almacenamiento peligroso.
• Un panel de administración sigue accesible con credenciales por defecto: mala configuración.

Estos ejemplos muestran que muchas vulnerabilidades nacen de decisiones cotidianas de desarrollo y operación, no necesariamente de escenarios excepcionales.

1.23 Qué habilidades desarrolla este curso

El objetivo del curso no es solo memorizar nombres de vulnerabilidades, sino desarrollar criterio técnico. A lo largo de los temas aprenderás a:

• Identificar superficies de ataque en aplicaciones y APIs.
• Entender la lógica de cada categoría de OWASP Top 10.
• Relacionar vulnerabilidades con impacto real de negocio y técnico.
• Reconocer errores típicos de diseño, implementación y configuración.
• Interpretar medidas de mitigación y buenas prácticas de desarrollo seguro.
• Adoptar una mirada más sistemática sobre autenticación, autorización, entrada de datos y exposición de información.

1.24 Qué debes recordar de este tema

• La seguridad web protege datos, sesiones, lógica de negocio, infraestructura y disponibilidad.
• Una vulnerabilidad puede originarse en diseño, código, configuración o procesos operativos.
• El cliente no es confiable; los controles críticos deben aplicarse en el servidor.
• OWASP es una referencia central para estudiar seguridad de aplicaciones.
• OWASP Top 10 resume categorías de riesgo frecuentes y de alto impacto, pero no cubre todo el universo de problemas.
• La seguridad debe pensarse durante todo el ciclo de vida del software, no solo al final.
• Comprender cómo funciona una aplicación web es indispensable para entender cómo puede ser atacada.

1.25 Conclusión

La seguridad web es una disciplina esencial porque las aplicaciones modernas concentran datos, procesos y decisiones críticas del negocio. Cuando una aplicación se diseña o implementa sin criterios de seguridad, no solo se expone a ataques técnicos, sino también a fraude, abuso funcional, pérdida de confianza y daños operativos.

OWASP Top 10 ofrece un marco muy valioso para empezar a estudiar este campo porque organiza los riesgos más relevantes en categorías comprensibles y prácticas. A partir de esta base, en los próximos temas analizaremos cómo funciona una aplicación web por dentro y luego profundizaremos en cada una de las principales vulnerabilidades.