El Proyecto | Sobre nosotros | Contribuir | Donaciones | Licencia

HOME

Ya sabes qué es OWASP y de dónde viene. Toca responder a la pregunta que da sentido a todo el curso: ¿por qué la seguridad de las aplicaciones web es tan importante? Si no interiorizas esta respuesta, la seguridad te parecerá una carga burocrática en lugar de una necesidad. En esta lección veremos por qué la web es un blanco tan atractivo, cuánto cuesta realmente una brecha, qué protegemos exactamente (la tríada CIA), y por qué la seguridad debe ser una propiedad transversal de todo el desarrollo y no un parche final. Todo aterrizado en lo que BazarNube se juega de verdad.

Nota: aquí veremos el porqué y el qué. El cómo integrarlo en el ciclo de desarrollo (el SDLC seguro) se trata en el módulo 7; en esta lección solo lo presentamos a alto nivel.

Contenido

Por qué la web es un blanco: la superficie de ataque
El valor de los datos y el cumplimiento normativo
El coste real de una brecha de seguridad
La tríada CIA: qué protegemos exactamente
La seguridad como propiedad transversal ("shift-left")
Qué se juega BazarNube

Por qué la web es un blanco: la superficie de ataque

Una aplicación web es, por definición, pública: está expuesta en internet para que cualquier usuario legítimo la use. El problema es que "cualquier usuario" incluye también a los atacantes. A diferencia de un programa interno, tu aplicación web está accesible 24/7 desde cualquier punto del planeta.

Llamamos superficie de ataque al conjunto de puntos por los que un atacante puede intentar entrar o interactuar con el sistema. Cuantos más puntos de entrada, mayor superficie. Una aplicación web moderna tiene muchos:

Cada endpoint de la API (rutas como /login, /productos, /pagos).
Cada formulario y campo de entrada del frontend.
Las cabeceras HTTP, las cookies y los tokens.
Las dependencias de terceros (librerías npm, paquetes de Java...).
La infraestructura que la aloja (contenedores, configuración de la nube).

graph LR
    ATK[Atacante<br/>desde cualquier lugar] --> EP1[/login/]
    ATK --> EP2[/productos/]
    ATK --> EP3[/pagos/]
    ATK --> DEP[Dependencias<br/>de terceros]
    ATK --> INFRA[Configuracion<br/>de la nube]
    subgraph Superficie de ataque de la aplicacion web
        EP1
        EP2
        EP3
        DEP
        INFRA
    end

La consecuencia práctica es demoledora: basta con que uno solo de esos puntos sea vulnerable para comprometer todo el sistema. El defensor tiene que proteger todos los puntos; el atacante solo necesita encontrar uno. Esa asimetría es la razón de fondo por la que la seguridad web es tan exigente.

El valor de los datos y el cumplimiento normativo

Los atacantes no atacan por deporte (normalmente): atacan porque hay algo valioso que obtener. Y las aplicaciones web custodian precisamente eso: datos.

Datos personales: nombres, correos, direcciones, teléfonos. Sirven para suplantación de identidad, spam o reventa.
Credenciales: usuarios y contraseñas, que se reutilizan en otros servicios.
Datos financieros: tarjetas, cuentas, historiales de pago. El objetivo más directo del fraude.

Como estos datos son sensibles, existen normativas que obligan a protegerlos. No necesitas dominarlas ahora (algunas se ven en módulos posteriores), pero sí reconocerlas a alto nivel:

Normativa	Qué protege	A quién aplica (a grandes rasgos)
GDPR / RGPD	Datos personales de ciudadanos de la UE.	Cualquier empresa que trate datos de europeos, esté donde esté.
PCI-DSS	Datos de tarjetas de pago.	Cualquier empresa que almacene, procese o transmita pagos con tarjeta.
HIPAA	Datos de salud (contexto EE. UU.).	Entidades sanitarias y sus proveedores.

La consecuencia clave: la seguridad no es solo una buena idea técnica, es una obligación legal. Incumplir GDPR o PCI-DSS puede acarrear multas cuantiosas y la pérdida de la capacidad de operar (por ejemplo, que tu proveedor de pagos te retire el servicio).

El coste real de una brecha de seguridad

Cuando una brecha ocurre, el coste va mucho más allá de "arreglar el bug". Conviene verlo desglosado, porque a menudo solo se piensa en la parte técnica, que suele ser la más pequeña:

Tipo de coste	Ejemplos
Directo / técnico	Investigar el incidente, parchear, restaurar sistemas, contratar peritos forenses.
Legal y regulatorio	Multas (GDPR/PCI-DSS), demandas de clientes afectados, obligación de notificar.
Reputacional	Pérdida de clientes, cobertura negativa en prensa, caída de confianza.
Operativo	Tiempo de inactividad, ventas perdidas, equipo dedicado a apagar el fuego en vez de construir.
A largo plazo	Mayores costes de seguros, dificultad para captar inversión o clientes.

Para una startup el golpe es especialmente peligroso: una empresa grande puede absorber una multa y una crisis reputacional, pero una startup joven puede no sobrevivir a una brecha grave. La confianza es su activo más frágil, y se pierde en un día.

La tríada CIA: qué protegemos exactamente

Cuando decimos "proteger", ¿qué protegemos? La seguridad de la información se resume clásicamente en tres propiedades, conocidas por sus siglas en inglés como CIA (nada que ver con la agencia): Confidentiality, Integrity, Availability.

Propiedad	Qué garantiza	Se rompe cuando...	Ejemplo en un e-commerce
Confidencialidad	Que solo quien está autorizado acceda a la información.	Un atacante lee datos que no debería.	Se filtra la base de datos de clientes.
Integridad	Que la información no se altere de forma no autorizada.	Alguien modifica datos sin permiso.	Un atacante cambia el precio de un pedido a 0 €.
Disponibilidad	Que el servicio esté accesible cuando se necesita.	El sistema deja de responder.	Un ataque tumba la tienda en plena campaña de rebajas.

graph TD
    S[Seguridad de la<br/>informacion] --> C[Confidencialidad<br/>solo acceso autorizado]
    S --> I[Integridad<br/>datos no alterados]
    S --> A[Disponibilidad<br/>servicio accesible]

La tríada CIA es una herramienta de análisis enormemente útil: ante cualquier riesgo, pregúntate cuál de las tres propiedades amenaza. Verás que casi todo encaja en una (o varias) de ellas. Es un vocabulario que usaremos durante todo el curso y que conecta directamente con el modelo de amenazas que construiremos para BazarNube.

Veámoslo con un fragmento de código. Este endpoint de la API de BazarNube tiene un problema clásico que compromete la confidencialidad y la integridad:

// API de BazarNube (Node.js + Express) - VERSION INSEGURA
app.get('/api/pedidos/:id', (req, res) => {
  // Se devuelve el pedido pedido por id SIN comprobar
  // si el usuario autenticado es su dueno.
  const pedido = db.pedidos.findById(req.params.id);
  res.json(pedido);
});

El problema: cualquier usuario autenticado puede pedir /api/pedidos/1, /api/pedidos/2, etc., y leer pedidos ajenos (rompe confidencialidad). Falta comprobar la propiedad del recurso. Una versión más segura sería:

// VERSION MEJORADA: se verifica que el pedido pertenece al usuario
app.get('/api/pedidos/:id', requireAuth, (req, res) => {
  const pedido = db.pedidos.findById(req.params.id);
  if (!pedido || pedido.usuarioId !== req.user.id) {
    // No revelamos si existe o no: devolvemos 404 en ambos casos
    return res.status(404).json({ error: 'No encontrado' });
  }
  res.json(pedido);
});

Aquí requireAuth garantiza que hay un usuario autenticado, y la comprobación pedido.usuarioId !== req.user.id garantiza que solo ve sus pedidos. No te preocupes por dominar este patrón ahora: lo estudiaremos a fondo en el módulo 3 (control de acceso). El objetivo aquí es que veas cómo una decisión de código concreta se traduce en una propiedad de la tríada CIA.

La seguridad como propiedad transversal ("shift-left")

Un error histórico muy extendido es tratar la seguridad como la última fase antes de lanzar: se construye todo y, al final, se hace una revisión de seguridad "a ver si pasa". Este enfoque falla por dos motivos:

Los fallos ya están cocidos en el diseño. Muchos problemas de seguridad nacen de decisiones de arquitectura tomadas al principio. Detectarlos al final significa rehacer, no parchear.
Arreglar tarde es carísimo. Corregir un fallo en producción cuesta mucho más —en tiempo y dinero— que evitarlo en la fase de diseño.

La alternativa se resume en una idea llamada "shift-left" (desplazar a la izquierda): mover las consideraciones de seguridad hacia el principio del proceso, no hacia el final. Si imaginas el ciclo de desarrollo como una línea de izquierda (idea/diseño) a derecha (producción), "shift-left" significa pensar en seguridad desde el extremo izquierdo.

graph LR
    D[Diseno] --> C[Codificacion] --> T[Pruebas] --> P[Produccion]
    S[Seguridad como<br/>propiedad transversal] -.-> D
    S -.-> C
    S -.-> T
    S -.-> P

Fíjate en las líneas punteadas: la seguridad toca todas las fases, no una sola. Es una propiedad transversal, como la calidad o el rendimiento: no es algo que "se añade" al final, sino algo que impregna cada decisión.

Aquí solo introducimos la idea. Cómo se organiza en la práctica dentro del ciclo de vida del desarrollo (el SDLC seguro, el modelado de amenazas, DevSecOps) es el tema del módulo 7; por ahora basta con que interiorices el principio: antes y durante, no solo al final.

Qué se juega BazarNube

Apliquemos todo a nuestro caso. Recuerda: BazarNube es un marketplace con datos de clientes, pagos y un módulo legacy de facturación en Java. Junto a Lucía, Marc y la SRE, empiezas a mapear qué riesgos concretos corre la empresa, clasificándolos con la tríada CIA. Este es el germen del backlog de hallazgos que construiremos a lo largo del curso:

Activo en riesgo	Qué podría pasar	Propiedad CIA amenazada	Impacto para BazarNube
Base de datos de clientes	Filtración de datos personales	Confidencialidad	Multa GDPR + pérdida de confianza
Datos de pago	Robo de datos de tarjetas	Confidencialidad	Sanción PCI-DSS + fraude a clientes
Precios y pedidos	Manipulación del importe a pagar	Integridad	Pérdidas económicas directas
Disponibilidad de la tienda	Caída durante una campaña	Disponibilidad	Ventas perdidas + daño reputacional
Módulo legacy en Java	Vulnerabilidad sin parchear	Confidencialidad / Integridad	Puerta de entrada al resto del sistema

Para una startup como BazarNube, las tres consecuencias más temidas se resumen así:

Datos de clientes: una filtración destruiría la confianza que tanto cuesta ganar.
Pagos: un incidente con tarjetas implicaría sanciones y podría dejarles sin proveedor de pagos.
Reputación: en un mercado competitivo, "la tienda a la que hackearon" es una etiqueta que espanta clientes e inversores.

Con este mapa inicial, el equipo entiende que la seguridad no es opcional ni cosmética: es una condición para sobrevivir y crecer. Y ahora tiene la motivación para adentrarse en las herramientas concretas de OWASP.

Errores Comunes y Consejos

Pensar "a mí no me van a atacar". Los ataques hoy son en gran medida automatizados: bots rastrean internet buscando cualquier aplicación vulnerable, sin importar el tamaño de la empresa. Ser pequeño no te hace invisible, te hace un blanco fácil.
Reducir la seguridad a la confidencialidad. Mucha gente solo piensa en "que no roben datos". Integridad y disponibilidad son igual de importantes: un precio manipulado o una tienda caída también son incidentes graves.
Dejar la seguridad para el final. Es el error más caro. Aplica el principio "shift-left": piensa en seguridad desde el diseño.
Ignorar el cumplimiento hasta que "toque". GDPR y PCI-DSS aplican desde el primer cliente, no cuando eres grande. Ignorarlos al principio crea una deuda que estalla en el peor momento.
Consejo: ante cualquier funcionalidad nueva, pregúntate: "¿qué propiedad de la CIA pone en riesgo y quién querría atacarla?". Es el primer paso del modelado de amenazas.

Ejercicios

Ejercicio 1. Para cada incidente, indica qué propiedad de la tríada CIA se ve comprometida principalmente: (a) un atacante descarga la lista de correos de todos los clientes; (b) un atacante modifica el saldo de su monedero en la tienda; (c) un ataque masivo deja la web inaccesible durante horas.

Ejercicio 2. BazarNube va a añadir una función de "exportar mis pedidos a PDF". Antes de programarla, aplica el principio "shift-left": enumera al menos dos preguntas de seguridad que deberíais haceros en la fase de diseño (no al final).

Ejercicio 3. Explica, en 4-6 líneas, por qué una brecha de seguridad puede ser más peligrosa para una startup como BazarNube que para una gran corporación, usando al menos dos de los tipos de coste vistos en el apartado 3.

Soluciones

Solución 1. (a) Confidencialidad (se accede a datos que deberían ser privados); (b) Integridad (se alteran datos —el saldo— sin autorización); (c) Disponibilidad (el servicio deja de estar accesible).

Solución 2. Ejemplos de preguntas de diseño (bastan dos):

¿Cómo garantizamos que un usuario solo puede exportar sus pedidos y no los de otro? (control de acceso, confidencialidad).
¿El PDF podría incluir datos sensibles (como datos de pago) que no deberían aparecer? (minimización de datos).
¿La generación del PDF podría abusarse para saturar el servidor si alguien la invoca en masa? (disponibilidad).
¿Dónde se almacena temporalmente el PDF y quién puede acceder a él? Plantear esto antes de codificar evita rehacer la función más tarde.

Solución 3. Una gran corporación puede absorber los costes legales y regulatorios (una multa) y los costes reputacionales (una crisis de imagen) gracias a su tamaño, sus reservas y su base de clientes consolidada. Una startup como BazarNube, en cambio, depende críticamente de la confianza de sus primeros clientes e inversores: un daño reputacional puede provocar una fuga masiva de usuarios, y un coste operativo elevado (parón de ventas, equipo apagando fuegos) puede agotar su escasa tesorería. La suma puede llevarla directamente al cierre, algo mucho menos probable en una empresa grande.

Conclusión

En esta lección has entendido por qué la seguridad web es crítica: una aplicación pública tiene una superficie de ataque enorme y asimétrica, custodia datos valiosos sujetos a normativas como GDPR y PCI-DSS, y una brecha acarrea costes técnicos, legales, reputacionales y operativos que pueden hundir a una startup. Has incorporado la tríada CIA (confidencialidad, integridad, disponibilidad) como herramienta para clasificar riesgos, y el principio "shift-left": la seguridad es una propiedad transversal, no una fase final. Y has trazado el primer mapa de riesgos de BazarNube, el germen del backlog que iremos ampliando.

Con esto cerramos el módulo 1. Ya sabes qué es OWASP, de dónde viene y por qué la seguridad importa. En el módulo 2 pasaremos de la teoría a la caja de herramientas: recorreremos los principales proyectos de OWASP —empezando por el célebre OWASP Top Ten, la lista de los diez riesgos más críticos— para empezar a ponerles nombre concreto a las amenazas que hoy solo hemos esbozado para BazarNube.

Importancia de la Seguridad en Aplicaciones Web

Contenido

Por qué la web es un blanco: la superficie de ataque

El valor de los datos y el cumplimiento normativo

El coste real de una brecha de seguridad

La tríada CIA: qué protegemos exactamente

La seguridad como propiedad transversal ("shift-left")

Qué se juega BazarNube

Errores Comunes y Consejos

Ejercicios

Soluciones

Conclusión

Curso de OWASP: Directrices y Estándares para la Seguridad en Aplicaciones Web

Módulo 1: Introducción a OWASP

Módulo 2: Principales Proyectos de OWASP

Módulo 3: OWASP Top Ten 2021 en Profundidad

Módulo 4: OWASP ASVS (Application Security Verification Standard)

Módulo 5: OWASP SAMM (Software Assurance Maturity Model)

Módulo 6: OWASP ZAP (Zed Attack Proxy)

Módulo 7: Buenas Prácticas y Recomendaciones

Módulo 8: Ejercicios Prácticos y Casos de Estudio

Módulo 9: Evaluación y Certificación