La seguridad no es una funcionalidad que se "añade al final": es una propiedad transversal que debe estar presente desde la primera línea del diseño. Esto es lo que significa seguridad por diseño (security by design). Un sistema que funciona, escala y está siempre disponible no sirve de nada si un atacante puede robar los datos de los usuarios o suplantar su identidad. En esta lección aprenderás los principios fundamentales de la seguridad (defensa en profundidad y mínimo privilegio), la diferencia esencial entre autenticación y autorización, los protocolos modernos que las implementan (OAuth2, OIDC y JWT), las vulnerabilidades más frecuentes según OWASP y, por último, cómo proteger los datos mediante cifrado en tránsito y en reposo.

Nota profesional: el contenido de esta lección es educativo sobre arquitectura. Cualquier implementación real de seguridad en un sistema de producción debe ser revisada por especialistas en seguridad y cumplir la normativa aplicable (por ejemplo GDPR/LOPDGDD).

1. Principios: defensa en profundidad y mínimo privilegio
2. Autenticación vs Autorización
3. OAuth2, OpenID Connect y JWT
4. OWASP Top 10 resumido
5. Cifrado en tránsito y en reposo
6. Errores comunes y consejos
7. Ejercicios

Dos principios sostienen toda arquitectura segura.

La defensa en profundidad consiste en no confiar en una única barrera, sino en colocar múltiples capas de seguridad independientes. Si una falla, las demás siguen protegiendo. Es el principio del castillo medieval: foso, muralla, puertas, torres.

Cada capa del diagrama protege de forma independiente: aunque un atacante atraviese el firewall, todavía debe superar la autenticación del gateway, la validación del servicio y los permisos de la base de datos.

El mínimo privilegio (least privilege) establece que cada usuario, servicio o proceso debe tener solo los permisos estrictamente necesarios para su función, ni uno más. Una cuenta de servicio que solo lee informes no debe poder borrar tablas.

En el ejemplo "MAL", si comprometen la aplicación, el atacante tiene control total de todas las bases de datos. En el "BIEN", solo puede leer y escribir en tienda, ni siquiera borrar (DELETE), y solo desde la red interna 10.0.%. El daño potencial queda contenido.

Estos dos conceptos se confunden constantemente, pero son distintos:

La regla mnemotécnica: AuthN = autenticNación (quién eres); AuthZ = autoriZación (qué puedes). Siempre se autentica primero y se autoriza después.

Los modelos de autorización más habituales son:

• RBAC (Role-Based Access Control): los permisos se asignan a roles (admin, editor, lector) y los usuarios reciben roles. Simple y muy extendido.
• ABAC (Attribute-Based Access Control): la decisión se basa en atributos (departamento, hora, ubicación, antigüedad). Más flexible y granular, pero más complejo.

Estos tres términos suelen mezclarse. La clave para no confundirse:

OAuth 2.0 permite que una aplicación acceda a recursos en nombre del usuario sin conocer su contraseña (por ejemplo, "Iniciar sesión con Google"). OIDC se construye encima de OAuth2 y añade la pieza que le faltaba: identificar al usuario, mediante un ID Token. JWT (JSON Web Token) es el formato más común en el que viajan esos tokens.

Un JWT tiene tres partes separadas por puntos: cabecera.payload.firma.

Punto crítico que confunde a los principiantes: el payload de un JWT no está cifrado, solo codificado en Base64. Cualquiera puede leerlo. Lo que garantiza la firma (la tercera parte) es la integridad y autenticidad: que nadie ha modificado el contenido y que lo emitió quien dice ser. Por eso nunca se deben poner secretos en un JWT.

Este código verifica que el token no ha sido manipulado (gracias a la firma) ni ha caducado (exp), y solo entonces extrae el identificador y los roles. Si la validación falla, lanza una excepción y se rechaza la petición.

OWASP (Open Worldwide Application Security Project) publica periódicamente el Top 10 de los riesgos de seguridad web más críticos. Es lectura obligada. Resumen de las categorías principales:

El ejemplo clásico es la inyección SQL (A03):

En la versión "MAL", un atacante puede inyectar SQL en el campo email y manipular la consulta. En la "BIEN", el ? es un marcador de posición: el motor nunca interpreta el valor del usuario como instrucciones SQL, eliminando la vulnerabilidad de raíz.

Los datos deben protegerse en sus dos estados:

• En tránsito (in transit): mientras viajan por la red. Se protege con TLS (el candado de HTTPS). Evita que alguien que intercepte el tráfico pueda leerlo (man in the middle).
• En reposo (at rest): mientras están almacenados en disco, base de datos o copias de seguridad. Se protege cifrando el almacenamiento o columnas concretas.

Este fragmento garantiza que nunca se sirva contenido por HTTP sin cifrar: el primer bloque redirige (código 301) todo el tráfico del puerto 80 a HTTPS. El segundo configura TLS permitiendo solo las versiones 1.2 y 1.3 (las antiguas tienen vulnerabilidades conocidas).

Una regla esencial sobre contraseñas: nunca se cifran ni se guardan en texto plano; se aplican funciones de hash lentas y con sal (bcrypt, scrypt, Argon2). Así, aunque roben la base de datos, no pueden recuperar las contraseñas originales.

• Confiar solo en el cliente. La validación y la autorización del navegador o la app móvil se pueden saltar trivialmente. Todo se valida y autoriza en el servidor.
• Creer que el JWT está cifrado. No lo está. No metas datos sensibles en el payload; cualquiera puede leerlo.
• Inventar tu propia criptografía. Casi siempre termina mal. Usa librerías y protocolos estándar, revisados y mantenidos.
• Guardar contraseñas con MD5/SHA o en claro. Usa funciones de hash diseñadas para contraseñas (bcrypt, Argon2) con sal.
• Mensajes de error demasiado detallados. Decir "el usuario no existe" frente a "contraseña incorrecta" ayuda al atacante. Responde de forma genérica.
• No actualizar dependencias. Las librerías obsoletas (A06) son una de las vías de ataque más frecuentes. Escanea y actualiza.
• Consejo: piensa como un atacante. En cada entrada de datos pregúntate "¿qué pasa si esto es malicioso?".

1. AuthN vs AuthZ. Un usuario inicia sesión correctamente pero, al intentar acceder al panel de administración, recibe un error 403 (Prohibido). ¿Falló la autenticación o la autorización? Justifícalo.

2. Detectar la vulnerabilidad. Revisa este código y di qué riesgo del OWASP Top 10 contiene y cómo lo corregirías:

   String consulta = "SELECT * FROM productos WHERE nombre = '" + busqueda + "'";
   statement.executeQuery(consulta);
   

3. Decisión de cifrado. Una aplicación de mensajería envía mensajes entre usuarios y los almacena en su base de datos. ¿Qué tipos de cifrado necesita y por qué cada uno?

1. Falló la autorización (AuthZ), no la autenticación. El error 403 (Prohibido) significa que el sistema sabe quién es el usuario (se autenticó bien, no es un 401), pero ese usuario no tiene permisos para acceder al panel de administración. Si hubiera fallado la autenticación, el código sería 401 (No autorizado/no identificado).

2. Es inyección SQL (A03): la variable busqueda se concatena directamente en la consulta, permitiendo a un atacante manipular el SQL. Corrección con consulta parametrizada:

   PreparedStatement ps = conn.prepareStatement(
       "SELECT * FROM productos WHERE nombre = ?");
   ps.setString(1, busqueda);
   ps.executeQuery();
   

   El ? impide que el valor del usuario se interprete como código SQL.

3. Necesita ambos. Cifrado en tránsito (TLS/HTTPS) para que nadie pueda interceptar los mensajes mientras viajan por la red entre el dispositivo y el servidor. Y cifrado en reposo para proteger los mensajes almacenados en la base de datos frente al robo del disco o de una copia de seguridad. (Las apps más exigentes añaden cifrado de extremo a extremo, donde ni el propio servidor puede leerlos.)

Has aprendido que la seguridad se diseña desde el principio mediante capas (defensa en profundidad) y permisos mínimos, que autenticar (quién eres) es distinto de autorizar (qué puedes), que OAuth2/OIDC/JWT son las piezas estándar de la identidad moderna, que el OWASP Top 10 cataloga los riesgos que debes conocer, y que los datos se cifran tanto en tránsito como en reposo. La seguridad nunca es un producto terminado: es un proceso continuo de prevención, detección y mejora.

Y para detectar tanto ataques como problemas de rendimiento necesitamos ver qué ocurre dentro del sistema. En la siguiente lección, Observabilidad: Logging, Métricas y Trazabilidad, aprenderemos a instrumentar la aplicación para entender su comportamiento en producción.