Seguridad de aplicaciones Java y Spring

La seguridad no es una capa que se añade al final: es una propiedad del diseño. Este módulo recorre los principios (CIA, defensa en profundidad, mínimo privilegio, confianza cero), la criptografía que de verdad vas a usar, la arquitectura completa de Spring Security 6, la autenticación con tokens, OAuth 2 y OpenID Connect, el OWASP Top 10 con código vulnerable y su corrección, la cadena de suministro, la privacidad y el proceso. Siempre con el por qué, porque una regla de seguridad que no entiendes es una regla que acabarás desactivando “solo en desarrollo”.

1. Fundamentos: principios y modelado de amenazas

1.1 La tríada CIA: qué proteges exactamente

Todo requisito de seguridad se reduce a tres propiedades. Nombrarlas te obliga a ser concreto y evita frases vacías del tipo “la aplicación tiene que ser segura”.

A la tríada clásica se le añaden dos propiedades imprescindibles en sistemas de negocio: autenticidad (el mensaje viene de quien dice venir) y no repudio (quien hizo algo no puede negarlo después, gracias a la auditoría).

1.2 Los siete principios que debes poder recitar

1.3 Modelado de amenazas con STRIDE, aplicado de verdad

Modelar amenazas es una reunión de una hora con un diagrama, no un documento de ochenta páginas. El procedimiento honesto son las cuatro preguntas de Adam Shostack: ¿en qué estamos trabajando? (diagrama), ¿qué puede salir mal? (STRIDE), ¿qué vamos a hacer? (mitigaciones con dueño y fecha) y ¿lo hemos hecho bien? (revisión).

DIAGRAMA DE FLUJO DE DATOS DE LA API DE PEDIDOS (lo que dibujas en la pizarra)

   ┌─────────────┐   1. HTTPS      ┌───────────────┐   3. HTTPS/mTLS   ┌──────────────┐
   │  Navegador  │────────────────►│               │──────────────────►│  Servicio    │
   │    (SPA)    │◄────────────────│  API pedidos  │◄──────────────────│   de pagos   │
   └─────────────┘                 │ (Spring Boot) │                   └──────────────┘
         │                         └───┬───────┬───┘
         │ 2. Authorization Code        │       │  4. JDBC sobre TLS
         │    + PKCE                    │       ▼
         ▼                              │   ┌──────────────┐
   ┌─────────────┐  valida el JWT       │   │  PostgreSQL  │
   │  Keycloak   │◄─── con el JWKS ─────┘   │  (cifrado    │
   │  (AS/OIDC)  │                          │   en reposo) │
   └─────────────┘                          └──────────────┘

 ════ LÍMITES DE CONFIANZA (trust boundaries) ════
  A) Navegador ↔ API      : todo dato de entrada es hostil. NADA de lógica en el cliente.
  B) API ↔ Keycloak       : confío en la FIRMA del token, no en la red.
  C) API ↔ pagos          : otro equipo, otro despliegue → identidad propia y autorización.
  D) API ↔ base de datos  : credenciales, mínimo privilegio y cifrado del canal.

 Cada FLECHA que cruza un límite de confianza es donde se aplica STRIDE.

1.4 Autenticación, autorización y auditoría no son lo mismo

2. Criptografía aplicada: lo justo y sin errores

2.1 Hash, cifrado y firma: tres cosas distintas

2.2 Hashing de contraseñas: el caso que sí te va a tocar

MD5, SHA-1, SHA-256 y SHA-512 no sirven para contraseñas. No porque estén “rotos” en el sentido de las colisiones (SHA-256 está perfectamente bien como hash), sino porque están diseñados para ser rapidísimos: exactamente lo contrario de lo que necesitas aquí. Una GPU moderna calcula del orden de miles de millones de SHA-256 por segundo, así que un diccionario con los miles de millones de contraseñas filtradas históricas se prueba en minutos.

Un algoritmo de contraseñas necesita tres propiedades que SHA no tiene:

1. Salt aleatorio y único por usuario. Impide precomputar tablas (rainbow tables) y hace que dos usuarios con la misma contraseña tengan hashes distintos. El salt no es secreto: se guarda junto al hash.
2. Coste configurable (factor de trabajo). El hash tarda deliberadamente 100–500 ms. Para ti es imperceptible; para quien prueba millones de candidatos es un muro. Y se puede subir con los años sin cambiar de algoritmo.
3. Coste de memoria en los algoritmos modernos. Argon2 y SCrypt exigen decenas de MiB por cálculo, lo que arruina la ventaja de las GPU y los ASIC, que tienen mucha unidad aritmética pero poca memoria por núcleo.

// ❌ INCORRECTO — todas estas variantes se han visto en producción y todas son inaceptables
usuario.setPassword(password);                                    // texto plano
usuario.setPassword(DigestUtils.md5Hex(password));                // MD5: se rompe en segundos
usuario.setPassword(sha256(password));                            // rápido → fuerza bruta trivial
usuario.setPassword(sha256(SAL_GLOBAL + password));               // salt único global: inútil
usuario.setPassword(Base64.getEncoder().encodeToString(bytes));   // Base64 NO es cifrado
usuario.setPassword(cifrarAes(password, CLAVE));                  // reversible: roban la clave,
                                                                  // roban todas las contraseñas

// ✅ CORRECTO — delega en Spring Security y no toques el algoritmo a mano
@Bean
PasswordEncoder passwordEncoder() {
    // Devuelve un DelegatingPasswordEncoder: codifica con el algoritmo por defecto (bcrypt)
    // y sabe VERIFICAR cualquiera de los formatos históricos gracias al prefijo {id}.
    return PasswordEncoderFactories.createDelegatingPasswordEncoder();
}

// Alta de usuario
String hash = passwordEncoder.encode(passwordEnClaro);
// hash → "{bcrypt}$2a$10$N9qo8uLOickgx2ZMRZoMye/Ci1Xh0zqQ8pEeS6PfLZKuHNP7BvJ2u"
//          └──┬───┘└┬┘└┬┘└──────── salt (22 caracteres) ──┘└────── hash ──────┘
//             │     │  └ coste = 2^10 = 1024 iteraciones internas
//             │     └── versión del algoritmo bcrypt
//             └──────── identificador que permite migrar de algoritmo sin romper nada

// Verificación: NUNCA compares hashes tú mismo, ni con equals ni con ==
boolean ok = passwordEncoder.matches(passwordRecibido, usuario.getPasswordHash());

// Elección explícita del algoritmo cuando quieres Argon2id (recomendación de OWASP)
@Bean
PasswordEncoder passwordEncoderArgon2() {
    String idPorDefecto = "argon2";
    Map<String, PasswordEncoder> codificadores = Map.of(
            "argon2", Argon2PasswordEncoder.defaultsForSpringSecurity_v5_8(),
            "bcrypt", new BCryptPasswordEncoder(12),
            "scrypt", SCryptPasswordEncoder.defaultsForSpringSecurity_v5_8(),
            "pbkdf2", Pbkdf2PasswordEncoder.defaultsForSpringSecurity_v5_8());
    var delegante = new DelegatingPasswordEncoder(idPorDefecto, codificadores);
    // Cualquier hash antiguo SIN prefijo se asume bcrypt (soporte de migración):
    delegante.setDefaultPasswordEncoderForMatches(new BCryptPasswordEncoder());
    return delegante;
}

Migrar de algoritmo sin obligar a nadie a cambiar su contraseña

// El prefijo {id} de DelegatingPasswordEncoder permite convivencia y migración perezosa:
// en el momento del login (el ÚNICO momento en que tienes la contraseña en claro) rehasheas.
@Service
public class ServicioAutenticacion {

    private final PasswordEncoder encoder;
    private final RepositorioUsuarios repositorio;

    @Transactional
    public Usuario autenticar(String email, String password) {
        Usuario u = repositorio.porEmail(email)
                .orElseThrow(() -> new BadCredentialsException("Credenciales no válidas"));

        if (!encoder.matches(password, u.getPasswordHash())) {
            throw new BadCredentialsException("Credenciales no válidas");   // mensaje IDÉNTICO
        }

        // Migración transparente: si el hash usa un algoritmo o un coste antiguos, se regraba
        if (encoder.upgradeEncoding(u.getPasswordHash())) {
            u.setPasswordHash(encoder.encode(password));
            repositorio.guardar(u);
        }
        return u;
    }
}

2.3 Cifrado simétrico: AES-GCM bien hecho

Si necesitas guardar un dato y luego recuperarlo (un IBAN, el token de un proveedor externo, un número de historia clínica), usas cifrado simétrico autenticado (AEAD). En la JCA eso es AES/GCM/NoPadding. Tres reglas no negociables:

1. Nunca ECB. AES/ECB cifra cada bloque de 16 bytes de forma independiente, así que bloques de texto claro iguales producen bloques cifrados iguales y el patrón del original se ve a través del cifrado (el famoso “pingüino ECB”). Y ojo: Cipher.getInstance("AES") significa ECB en la implementación por defecto de la JDK. Escribe siempre el modo de forma explícita.
2. IV (nonce) aleatorio y único por mensaje. Reutilizar el par (clave, IV) en GCM es catastrófico: no solo se filtra información del texto claro, sino que permite recuperar la clave de autenticación y falsificar mensajes. El IV no es secreto: se guarda junto al criptograma.
3. Verifica la etiqueta. GCM ya lo hace: si el criptograma se ha manipulado, doFinal() lanza AEADBadTagException. No captures esa excepción para “seguir con lo que se pueda”.

// ❌ INCORRECTO — el catálogo de errores de cifrado en Java
Cipher c = Cipher.getInstance("AES");                       // = AES/ECB: patrón visible
Cipher d = Cipher.getInstance("AES/CBC/PKCS5Padding");      // sin MAC → maleable, padding oracle
byte[] iv = new byte[12];                                   // IV de ceros
byte[] iv2 = "1234567890ab".getBytes();                     // IV constante: rotura total en GCM
SecretKey k = new SecretKeySpec("claveSuperSecreta1234567890123456".getBytes(), "AES"); // en el código
Cipher e = Cipher.getInstance("DES/CBC/PKCS5Padding");      // DES, 3DES, RC4, Blowfish: obsoletos

// ✅ CORRECTO — AES-256-GCM con IV aleatorio por mensaje y datos asociados
public final class CifradoCampo {

    private static final String TRANSFORMACION = "AES/GCM/NoPadding";
    private static final int LONGITUD_IV = 12;        // 96 bits: el tamaño recomendado por NIST
    private static final int LONGITUD_TAG_BITS = 128; // etiqueta de autenticación completa
    private static final SecureRandom ALEATORIO = new SecureRandom();

    private final SecretKey clave;   // inyectada desde un KMS o desde un secreto de la plataforma

    public CifradoCampo(SecretKey clave) { this.clave = clave; }

    /**
     * Devuelve  iv || criptograma+etiqueta  en Base64 URL-safe.
     * @param datosAsociados contexto NO cifrado pero SÍ autenticado (p. ej. "usuario:4711:iban").
     *                       Impide mover un criptograma válido de una fila a otra.
     */
    public String cifrar(byte[] claro, byte[] datosAsociados) throws GeneralSecurityException {
        byte[] iv = new byte[LONGITUD_IV];
        ALEATORIO.nextBytes(iv);                               // ← nuevo IV en CADA llamada

        Cipher cipher = Cipher.getInstance(TRANSFORMACION);
        cipher.init(Cipher.ENCRYPT_MODE, clave, new GCMParameterSpec(LONGITUD_TAG_BITS, iv));
        cipher.updateAAD(datosAsociados);
        byte[] criptograma = cipher.doFinal(claro);            // incluye la etiqueta al final

        byte[] salida = new byte[iv.length + criptograma.length];
        System.arraycopy(iv, 0, salida, 0, iv.length);
        System.arraycopy(criptograma, 0, salida, iv.length, criptograma.length);
        return Base64.getUrlEncoder().withoutPadding().encodeToString(salida);
    }

    public byte[] descifrar(String base64, byte[] datosAsociados) throws GeneralSecurityException {
        byte[] todo = Base64.getUrlDecoder().decode(base64);
        if (todo.length <= LONGITUD_IV) throw new IllegalArgumentException("criptograma truncado");

        GCMParameterSpec spec = new GCMParameterSpec(LONGITUD_TAG_BITS, todo, 0, LONGITUD_IV);
        Cipher cipher = Cipher.getInstance(TRANSFORMACION);
        cipher.init(Cipher.DECRYPT_MODE, clave, spec);
        cipher.updateAAD(datosAsociados);
        // Si alguien tocó un solo bit → AEADBadTagException. Déjala subir: el dato NO es de fiar.
        return cipher.doFinal(todo, LONGITUD_IV, todo.length - LONGITUD_IV);
    }
}

// Derivar una clave AES a partir de una contraseña (solo si NO tienes KMS)
SecretKeyFactory fabrica = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
KeySpec spec = new PBEKeySpec(passphrase.toCharArray(), salt, 600_000, 256);
SecretKey clave = new SecretKeySpec(fabrica.generateSecret(spec).getEncoded(), "AES");

2.4 Asimétrico, firmas y certificados

El cifrado asimétrico resuelve el problema del huevo y la gallina: cómo acordar un secreto con alguien con quien nunca has hablado, por un canal que alguien está escuchando. Es lento (miles de veces más que AES), así que no se usa para cifrar datos, sino para tres cosas:

• Acordar una clave de sesión (lo que hace TLS con ECDHE) que luego se usa con AES.
• Firmar: yo firmo con mi clave privada; cualquiera verifica con mi pública. Es lo que hacen un JWT RS256 y un certificado.
• Cifrar secretos pequeños para un destinatario concreto (RSA-OAEP, nunca PKCS#1 v1.5, por el ataque de Bleichenbacher).

// Firmar y verificar: el patrón es siempre el mismo
KeyPairGenerator gen = KeyPairGenerator.getInstance("Ed25519");
KeyPair par = gen.generateKeyPair();

Signature firmador = Signature.getInstance("Ed25519");
firmador.initSign(par.getPrivate());
firmador.update(mensaje);
byte[] firma = firmador.sign();                        // solo el dueño de la privada puede producirla

Signature verificador = Signature.getInstance("Ed25519");
verificador.initVerify(par.getPublic());               // la pública se puede publicar sin miedo
verificador.update(mensaje);
boolean valida = verificador.verify(firma);            // ← ¿compruebas el RESULTADO? Es obligatorio

if (!valida) throw new SecurityException("firma no válida");

// ⚠️ El fallo real más común con firmas no es criptográfico: es IGNORAR el booleano de verify()
//    o capturar la excepción y continuar. Ese "if" salva sistemas enteros.

Certificados y cadena de confianza

Una clave pública por sí sola no dice nada: ¿de quién es? Un certificado X.509 es una clave pública, más una identidad (el subject, hoy siempre en la extensión SAN), más un periodo de validez, todo firmado por una autoridad de certificación (CA). Tu navegador confía en unas ciento cincuenta CA raíz preinstaladas; a partir de ahí, la confianza se hereda por la cadena.

CADENA DE CONFIANZA

 ┌──────────────────────────┐
 │  CA raíz (autofirmada)   │  Está en el truststore del sistema o de la JVM (cacerts).
 │  clave privada offline   │  Si esta se compromete, se cae todo el sistema.
 └────────────┬─────────────┘
              │ firma
 ┌────────────▼─────────────┐
 │  CA intermedia           │  Firma el día a día. El servidor DEBE enviarla también
 └────────────┬─────────────┘  (olvidarla = "certificado no válido" solo en algunos clientes).
              │ firma
 ┌────────────▼─────────────┐
 │ Certificado del servidor │  SAN = api.miempresa.com · validez 90 días (ACME/Let's Encrypt)
 └──────────────────────────┘

VALIDACIÓN QUE HACE EL CLIENTE (todas, no solo la primera):
 1. La firma de cada eslabón es correcta y llega a una raíz de confianza.
 2. Ninguno está caducado ni es todavía futuro (¡reloj del contenedor sincronizado!).
 3. El nombre solicitado coincide con una SAN del certificado.
 4. El certificado no está revocado (OCSP stapling o CRL).
 5. Los usos de clave y las restricciones básicas son coherentes.

❌ Desactivar el paso 1 o el 3 (un "TrustManager que acepta todo", un "HostnameVerifier que
   devuelve true") convierte TLS en cifrado SIN autenticación: cualquiera puede ponerse en
   medio. Es la vulnerabilidad más frecuente en clientes móviles y en integraciones internas
   "provisionales".

2.5 TLS: el handshake, mTLS y cómo se configura

HANDSHAKE DE TLS 1.3 (1 RTT: la mitad que en TLS 1.2)

    CLIENTE                                                       SERVIDOR
       │                                                              │
       │──── ClientHello ────────────────────────────────────────────►│
       │      · versiones soportadas (1.3)                            │
       │      · cipher suites (TLS_AES_128_GCM_SHA256…)                │
       │      · key_share: mi parte pública de ECDHE (X25519)          │
       │      · SNI: api.miempresa.com   · ALPN: h2                    │
       │                                                              │
       │◄─── ServerHello ─────────────────────────────────────────────│
       │      · cipher suite elegida                                  │
       │      · key_share: su parte pública de ECDHE                   │
       │      ══ desde aquí TODO va cifrado ══                         │
       │      · {EncryptedExtensions}                                  │
       │      · {Certificate}        ← cadena X.509                    │
       │      · {CertificateVerify}  ← firma que demuestra que tiene   │
       │                               la clave privada del cert.     │
       │      · {Finished}                                             │
       │                                                              │
       │   [el cliente valida la cadena, el nombre y las fechas]      │
       │                                                              │
       │──── {Finished} ─────────────────────────────────────────────►│
       │──── {datos de aplicación: GET /pedidos} ────────────────────►│

CLAVE DEL DISEÑO: la clave de sesión sale de ECDHE, es EFÍMERA y nunca viaja por la red.
Aunque un atacante grabe todo el tráfico y años después robe la clave privada del servidor,
NO puede descifrar lo grabado → forward secrecy, obligatoria en TLS 1.3.

TLS 1.3 eliminó: RSA como transporte de clave, Diffie-Hellman estático, la renegociación,
la compresión (CRIME), MD5 y SHA-1, RC4, los modos CBC y todos los cipher suites no AEAD.
→ "usa TLS 1.3, y 1.2 solo como respaldo" es una configuración correcta y suficiente.

mTLS (TLS mutuo) añade un paso: el servidor pide también un certificado al cliente y verifica su cadena. Deja de haber “clientes anónimos con token”; hay identidades criptográficas a nivel de conexión. Es el mecanismo estándar para servicio a servicio y la base de las mallas de servicio (Istio, Linkerd), que lo aplican de forma transparente. Véase el módulo 08.

# application.yml — TLS en Spring Boot 3.x con SSL bundles (3.1+)
server:
  port: 8443
  ssl:
    enabled: true
    bundle: servidor
    client-auth: none          # need = mTLS obligatorio · want = opcional
spring:
  ssl:
    bundle:
      jks:
        servidor:
          key:
            alias: api
          keystore:
            location: file:/etc/tls/keystore.p12
            password: ${KEYSTORE_PASSWORD}      # NUNCA literal en el fichero
            type: PKCS12
          truststore:                            # solo necesario para mTLS
            location: file:/etc/tls/truststore.p12
            password: ${TRUSTSTORE_PASSWORD}
            type: PKCS12
      # Un bundle PEM es más cómodo con cert-manager en Kubernetes:
      pem:
        interno:
          keystore:
            certificate: file:/etc/tls/tls.crt
            private-key: file:/etc/tls/tls.key
          truststore:
            certificate: file:/etc/tls/ca.crt

# Generar material de prueba (SOLO para desarrollo local)
keytool -genkeypair -alias api -keyalg EC -groupname secp256r1 \
        -storetype PKCS12 -keystore keystore.p12 \
        -validity 365 -dname "CN=localhost" \
        -ext "SAN=dns:localhost,ip:127.0.0.1"

# Inspeccionar lo que sirve un servidor de verdad
openssl s_client -connect api.miempresa.com:443 -servername api.miempresa.com -tls1_3 < /dev/null
openssl s_client -connect api.miempresa.com:443 -showcerts 2>/dev/null \
  | openssl x509 -noout -dates -text

# Ver qué versiones y suites acepta (auditoría rápida)
nmap --script ssl-enum-ciphers -p 443 api.miempresa.com
# En producción, la referencia pública es SSL Labs (ssllabs.com/ssltest). Objetivo: A o A+.

server:
  # Detrás de un proxy, para que Spring sepa el esquema y la IP originales y genere URLs https
  forward-headers-strategy: framework      # confía en X-Forwarded-* (el proxy DEBE sanearlos)
  tomcat:
    remoteip:
      remote-ip-header: x-forwarded-for
      protocol-header: x-forwarded-proto
  error:
    include-stacktrace: never              # jamás un stack trace al cliente
    include-message: never
    include-binding-errors: never
  servlet:
    session:
      cookie:
        http-only: true                    # el JavaScript no puede leer la cookie
        secure: true                       # solo se envía por HTTPS
        same-site: lax                     # mitiga CSRF; strict si no necesitas navegación entrante

// Redirigir HTTP a HTTPS y forzar HSTS lo hace normalmente el ingress; en la aplicación:
http.requiresChannel(canal -> canal.anyRequest().requiresSecure())
    .headers(h -> h.httpStrictTransportSecurity(hsts -> hsts
            .includeSubDomains(true)
            .preload(true)
            .maxAgeInSeconds(31_536_000)));   // 1 año

// ⚠️ HSTS es una decisión IRREVERSIBLE durante max-age para los navegadores que ya lo vieron.
//    No lo actives con includeSubDomains sobre un dominio del que algún subdominio siga en HTTP.

2.6 Aleatoriedad, comparaciones y gestión de claves

// ❌ Random NO es seguro: es un generador congruencial de 48 bits, predecible con dos salidas.
String token = Long.toHexString(new Random().nextLong());            // adivinable
String otro  = UUID.nameUUIDFromBytes(email.getBytes()).toString();  // UUID v3: DETERMINISTA
int codigo   = (int) (Math.random() * 1_000_000);                    // OTP predecible

// ✅ SecureRandom para todo lo que deba ser impredecible
private static final SecureRandom RNG = new SecureRandom();   // reutilízalo: es thread-safe

public static String tokenOpaco() {
    byte[] bytes = new byte[32];                              // 256 bits de entropía
    RNG.nextBytes(bytes);
    return Base64.getUrlEncoder().withoutPadding().encodeToString(bytes);
}
String idPublico = UUID.randomUUID().toString();              // UUID v4: usa SecureRandom por dentro

// getInstanceStrong() para material de clave de larga vida
SecureRandom fuerte = SecureRandom.getInstanceStrong();

// ✅ Comparación en tiempo constante: obligatoria para tokens, MAC y códigos OTP.
// equals() sale en el primer byte distinto → filtra información por el TIEMPO de respuesta.
boolean malo  = tokenEsperado.equals(tokenRecibido);                       // ❌ canal lateral
boolean bueno = MessageDigest.isEqual(tokenEsperado.getBytes(UTF_8),
                                      tokenRecibido.getBytes(UTF_8));      // ✅ tiempo constante

// Y no guardes tokens de sesión ni API keys en claro: guarda su SHA-256 (son valores de alta
// entropía, no necesitan bcrypt) y compara hashes. Si roban la tabla, no roban tokens usables.

3. Spring Security 6: arquitectura y configuración moderna

3.1 La cadena de filtros: dónde ocurre todo

Spring Security es, en esencia, un solo filtro de servlet registrado en el contenedor (springSecurityFilterChain, envuelto en DelegatingFilterProxy) que delega en una o varias SecurityFilterChain. Cada cadena es una lista ordenada de filtros, y ese orden lo explica casi todo: por qué el CORS debe ir antes que la autorización, por qué el CSRF bloquea tu POST antes de llegar al controlador, o por qué un 403 aparece “sin que se ejecute tu código”.

PETICIÓN HTTP
     │
     ▼
FilterChainProxy   ── elige la PRIMERA SecurityFilterChain cuyo securityMatcher encaje
     │
     ▼   (orden real, simplificado a los filtros que de verdad te afectan)
┌────────────────────────────────────────────────────────────────────────────────────┐
│ 1  DisableEncodeUrlFilter          evita el jsessionid en la URL (fuga de sesión)  │
│ 2  WebAsyncManagerIntegrationFilter propaga el SecurityContext a peticiones async  │
│ 3  SecurityContextHolderFilter     CARGA el SecurityContext (de la sesión) y lo    │
│                                    limpia al final. En SS6 ya NO guarda solo;      │
│                                    el guardado es explícito (repository.saveContext)│
│ 4  HeaderWriterFilter              escribe CSP, X-Frame-Options, HSTS, nosniff…    │
│ 5  CorsFilter                      preflight OPTIONS y cabeceras Access-Control-*  │
│ 6  CsrfFilter                      valida el token CSRF en POST/PUT/PATCH/DELETE   │
│ 7  LogoutFilter                    /logout: invalida sesión y limpia contexto      │
│ 8  OAuth2AuthorizationRequestRedirectFilter   inicia el flujo Authorization Code   │
│ 9  UsernamePasswordAuthenticationFilter       procesa el POST del formulario login │
│10  DefaultLoginPageGeneratingFilter           la página de login "gratis"          │
│11  ConcurrentSessionFilter         control de sesiones simultáneas                 │
│12  BearerTokenAuthenticationFilter LEE "Authorization: Bearer …" (resource server)  │
│13  BasicAuthenticationFilter       HTTP Basic                                      │
│14  RequestCacheAwareFilter         reenvía a la URL que pedías antes del login     │
│15  SecurityContextHolderAwareRequestFilter   integra con la API de Servlet         │
│16  RememberMeAuthenticationFilter  cookie de "recuérdame"                          │
│17  AnonymousAuthenticationFilter   si NADIE autenticó, crea un Authentication      │
│                                    "anonymousUser" → nunca hay null a partir de aquí│
│18  SessionManagementFilter         protección de fijación de sesión                │
│19  ExceptionTranslationFilter      ⇦ CAPTURA las excepciones de los filtros de     │
│                                       abajo: AuthenticationException → 401 vía     │
│                                       AuthenticationEntryPoint                     │
│                                       AccessDeniedException  → 403 vía             │
│                                       AccessDeniedHandler                          │
│20  AuthorizationFilter             ⇦ APLICA authorizeHttpRequests (en SS5 era      │
│                                       FilterSecurityInterceptor). Lanza            │
│                                       AccessDeniedException, que sube al 19.       │
└────────────────────────────────────────────────────────────────────────────────────┘
     │  si nadie ha cortado la petición
     ▼
DispatcherServlet ──► @RestController ──► @Service con @PreAuthorize (segunda barrera)

CLAVE: el 19 envuelve al 20. Por eso un fallo de autorización se traduce en 403 "solo",
sin llegar a tu @ControllerAdvice. Y por eso el orden 5 antes que 20 permite que el
preflight OPTIONS del navegador funcione aunque el endpoint requiera autenticación.

3.2 Los objetos que tienes que conocer

// Obtener el usuario actual: tres formas, de mejor a peor
// ✅ 1. Inyección en el controlador: testeable y explícito
@GetMapping("/perfil")
public PerfilDto perfil(@AuthenticationPrincipal Jwt jwt) {
    return servicio.perfilDe(jwt.getSubject());
}

// ✅ 2. En un servicio, cuando de verdad hace falta el contexto
Authentication auth = SecurityContextHolder.getContext().getAuthentication();
String usuario = auth.getName();
boolean esAdmin = auth.getAuthorities().stream()
        .anyMatch(a -> "ROLE_ADMIN".equals(a.getAuthority()));

// ❌ 3. Pasar el "userId" como parámetro que envía el cliente
@GetMapping("/pedidos")                                    // el cliente decide QUIÉN es → suplantación
public List<PedidoDto> mios(@RequestParam String usuarioId) { … }

// Propagar la identidad a otro hilo (necesario con @Async y con hilos virtuales propios)
Executor seguro = new DelegatingSecurityContextExecutor(Executors.newVirtualThreadPerTaskExecutor());
seguro.execute(() -> log.info("Aquí sí veo a {}",
        SecurityContextHolder.getContext().getAuthentication().getName()));

3.3 Configuración moderna: componentes y lambda DSL

// ❌ ANTIGUO (Spring Security 5.x, ya eliminado) — solo para que lo reconozcas
@Configuration
public class SeguridadVieja extends WebSecurityConfigurerAdapter {
    @Override protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests()
                .antMatchers("/admin/**").hasRole("ADMIN")
                .anyRequest().authenticated()
            .and().formLogin()
            .and().csrf().disable();
    }
}

// ✅ MODERNO (Spring Boot 3.x / Spring Security 6.x)
@Configuration
@EnableWebSecurity
@EnableMethodSecurity            // activa @PreAuthorize/@PostAuthorize (prePost está en true por defecto)
public class ConfiguracionSeguridad {

    @Bean
    SecurityFilterChain cadenaWeb(HttpSecurity http) throws Exception {
        return http
            .authorizeHttpRequests(auth -> auth
                // El ORDEN IMPORTA: se evalúa de arriba abajo y gana la PRIMERA que encaja.
                .requestMatchers("/", "/css/**", "/js/**", "/webjars/**").permitAll()
                .requestMatchers("/actuator/health", "/actuator/info").permitAll()
                .requestMatchers("/admin/**").hasRole("ADMIN")           // busca ROLE_ADMIN
                .requestMatchers(HttpMethod.POST, "/pedidos").hasAuthority("pedidos:crear")
                .requestMatchers("/interno/**").hasIpAddress("10.0.0.0/8")
                .anyRequest().authenticated())                            // ← DENY BY DEFAULT: siempre al final
            .formLogin(login -> login
                .loginPage("/login").permitAll()
                .defaultSuccessUrl("/panel", false)
                .failureHandler(this::fallosDeLogin))                     // audita y no filtra el motivo
            .logout(logout -> logout
                .logoutUrl("/logout")                                     // por defecto exige POST con CSRF
                .invalidateHttpSession(true)
                .clearAuthentication(true)
                .deleteCookies("JSESSIONID")
                .logoutSuccessUrl("/?salida"))
            .sessionManagement(sesion -> sesion
                .sessionFixation(SessionFixationConfigurer::changeSessionId)  // por defecto ya
                .maximumSessions(3).maxSessionsPreventsLogin(false))
            .headers(h -> h
                .contentSecurityPolicy(csp -> csp.policyDirectives(
                        "default-src 'self'; object-src 'none'; base-uri 'self'; " +
                        "frame-ancestors 'none'; form-action 'self'"))
                .frameOptions(FrameOptionsConfig::deny)
                .referrerPolicy(r -> r.policy(ReferrerPolicy.STRICT_ORIGIN_WHEN_CROSS_ORIGIN))
                .httpStrictTransportSecurity(hsts -> hsts.includeSubDomains(true)
                                                         .maxAgeInSeconds(31_536_000))
                .permissionsPolicy(p -> p.policy("geolocation=(), camera=(), microphone=()")))
            .build();
    }

    @Bean
    PasswordEncoder passwordEncoder() {
        return PasswordEncoderFactories.createDelegatingPasswordEncoder();
    }

    @Bean
    UserDetailsService usuarios(RepositorioUsuarios repositorio) {
        return email -> repositorio.porEmail(email)
                .map(u -> User.withUsername(u.getEmail())
                        .password(u.getPasswordHash())        // ya viene con {bcrypt}…
                        .authorities(u.getAuthorities())
                        .accountLocked(u.estaBloqueado())
                        .credentialsExpired(u.debeCambiarPassword())
                        .build())
                .orElseThrow(() -> new UsernameNotFoundException("no encontrado"));
    }

    private void fallosDeLogin(HttpServletRequest req, HttpServletResponse res,
                               AuthenticationException ex) throws IOException {
        log.warn("login_fallido usuario={} ip={} motivo={}",
                 req.getParameter("username"), req.getRemoteAddr(), ex.getClass().getSimpleName());
        res.sendRedirect("/login?error");     // al usuario, un mensaje genérico
    }
}

3.4 Varias cadenas de filtros con securityMatcher

Es el caso real de casi cualquier aplicación: una API stateless con JWT y una parte web con formulario de login, cada una con reglas incompatibles (CSRF sí/no, sesión sí/no). No se resuelve con if: se declaran dos beans ordenados.

@Configuration
@EnableWebSecurity
public class ConfiguracionMultiple {

    @Bean
    @Order(1)                                    // se evalúa PRIMERO
    SecurityFilterChain api(HttpSecurity http) throws Exception {
        return http
            .securityMatcher("/api/**")          // esta cadena solo atiende /api/**
            .csrf(AbstractHttpConfigurer::disable)          // API con Bearer: no aplica (ver 3.7)
            .cors(cors -> cors.configurationSource(fuenteCors()))
            .sessionManagement(s -> s.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
            .authorizeHttpRequests(auth -> auth
                .requestMatchers(HttpMethod.OPTIONS, "/api/**").permitAll()   // preflight
                .requestMatchers("/api/publico/**").permitAll()
                .anyRequest().authenticated())
            .oauth2ResourceServer(oauth -> oauth.jwt(Customizer.withDefaults()))
            .exceptionHandling(ex -> ex
                .authenticationEntryPoint(new BearerTokenAuthenticationEntryPoint())   // 401 + WWW-Authenticate
                .accessDeniedHandler(new BearerTokenAccessDeniedHandler()))            // 403 correcto
            .build();
    }

    @Bean
    @Order(2)
    SecurityFilterChain actuadorInterno(HttpSecurity http) throws Exception {
        return http
            .securityMatcher(EndpointRequest.toAnyEndpoint())      // requiere spring-boot-actuator
            .authorizeHttpRequests(auth -> auth
                .requestMatchers(EndpointRequest.to("health", "info")).permitAll()
                .anyRequest().hasRole("OPERADOR"))
            .httpBasic(Customizer.withDefaults())
            .csrf(AbstractHttpConfigurer::disable)
            .build();
    }

    @Bean
    @Order(3)                                    // cajón de sastre: TODO lo demás
    SecurityFilterChain web(HttpSecurity http) throws Exception {
        return http
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/", "/login", "/registro", "/css/**").permitAll()
                .anyRequest().authenticated())
            .formLogin(Customizer.withDefaults())
            .build();                            // CSRF y sesión ACTIVADOS: es lo correcto aquí
    }
}

3.5 Autorización por método: la barrera que de verdad protege

La autorización por URL es necesaria pero insuficiente. Es frágil (una ruta nueva, un @RequestMapping refactorizado, una barra final, un alias) y no protege los caminos que no pasan por HTTP: un consumidor de Kafka, una tarea programada, un resolver de GraphQL o una llamada interna entre servicios. La autorización en la capa de servicio viaja con el código, no con la ruta.

@Service
@Transactional
public class ServicioPedidos {

    // Roles y authorities
    @PreAuthorize("hasRole('ADMIN')")
    public void cancelarTodos(LocalDate dia) { … }

    @PreAuthorize("hasAnyAuthority('pedidos:leer', 'pedidos:administrar')")
    public List<PedidoDto> listar(Pageable pagina) { … }

    // SpEL con los ARGUMENTOS del método (#nombre requiere -parameters al compilar,
    // que Spring Boot ya activa; si no, usa #p0 / @P("id"))
    @PreAuthorize("#nif == authentication.name or hasRole('SOPORTE')")
    public ClienteDto porNif(String nif) { … }

    // Con un bean propio: la forma limpia de expresar reglas de dominio
    @PreAuthorize("@guardiaPedidos.puedeVer(#id, authentication)")
    public PedidoDto ver(Long id) { … }

    // POSTautorización: la decisión depende del OBJETO DEVUELTO.
    // ⚠️ El método YA SE EJECUTÓ: si tenía efectos secundarios, ya ocurrieron.
    //    Con @Transactional se hace rollback, pero un email enviado no vuelve.
    @PostAuthorize("returnObject.clienteNif == authentication.name or hasRole('SOPORTE')")
    public PedidoDto detalle(Long id) { … }

    // Filtrar colecciones
    @PostFilter("filterObject.clienteNif == authentication.name")   // filtra lo DEVUELTO
    public List<PedidoDto> misPedidos() { … }

    @PreFilter("filterObject.importe <= 1000 or hasRole('ADMIN')")  // filtra el ARGUMENTO
    public void importar(List<LineaImportacion> lineas) { … }
}

// El bean de reglas: lógica de negocio testeable, no SpEL kilométrico
@Component("guardiaPedidos")
public class GuardiaPedidos {

    private final RepositorioPedidos repositorio;

    public boolean puedeVer(Long pedidoId, Authentication auth) {
        if (tieneRol(auth, "ROLE_SOPORTE")) return true;
        return repositorio.existePorIdYClienteNif(pedidoId, auth.getName());  // 1 consulta, sin cargar todo
    }

    private static boolean tieneRol(Authentication auth, String rol) {
        return auth.getAuthorities().stream().anyMatch(a -> rol.equals(a.getAuthority()));
    }
}

3.6 Autorización de dominio: “¿puede ver ESTE pedido?”

Esta es la pregunta que distingue una aplicación segura de una vulnerable, y la que Spring Security no puede responder por ti: solo tú sabes qué significa “ser dueño” en tu negocio. Y hay una forma correcta y una incorrecta de implementarla.

// ❌ VULNERABLE (IDOR): autenticado ≠ autorizado. Cambiando el id, ves pedidos ajenos.
@GetMapping("/pedidos/{id}")
public PedidoDto ver(@PathVariable Long id) {
    return mapper.aDto(repositorio.findById(id).orElseThrow());
}

// ⚠️ MEJOR, PERO FRÁGIL: comprueba después de cargar. Funciona, pero (a) se olvida en el
// siguiente endpoint, (b) carga datos que el usuario no puede ver, (c) el 403 confirma que existe.
@GetMapping("/pedidos/{id}")
public PedidoDto ver(@PathVariable Long id, @AuthenticationPrincipal Jwt jwt) {
    Pedido p = repositorio.findById(id).orElseThrow(PedidoNoEncontrado::new);
    if (!p.getClienteNif().equals(jwt.getSubject())) throw new AccessDeniedException("no es tuyo");
    return mapper.aDto(p);
}

// ✅ CORRECTO: la propiedad forma parte de la CONSULTA. No se puede olvidar,
//    no carga datos ajenos y devuelve 404 en lugar de 403 (no confirma la existencia).
public interface RepositorioPedidos extends JpaRepository<Pedido, Long> {
    Optional<Pedido> findByIdAndClienteNif(Long id, String nif);
    Page<Pedido> findAllByClienteNif(String nif, Pageable pagina);
}

@GetMapping("/pedidos/{id}")
public PedidoDto ver(@PathVariable Long id, @AuthenticationPrincipal Jwt jwt) {
    return repositorio.findByIdAndClienteNif(id, jwt.getSubject())
            .map(mapper::aDto)
            .orElseThrow(PedidoNoEncontrado::new);     // → 404, mismo resultado exista o no
}

// ✅ Y cuando las reglas son ricas (roles + propiedad + delegación + estado), un AuthorizationManager
@Component
public class PedidoAuthorizationManager
        implements AuthorizationManager<RequestAuthorizationContext> {

    private final RepositorioPedidos repositorio;

    @Override
    public AuthorizationDecision check(Supplier<Authentication> authentication,
                                       RequestAuthorizationContext contexto) {
        Authentication auth = authentication.get();
        String id = contexto.getVariables().get("id");        // variable de la plantilla de ruta
        if (id == null || auth == null || !auth.isAuthenticated()) {
            return new AuthorizationDecision(false);          // fallar de forma segura
        }
        boolean permitido = repositorio.puedeAcceder(Long.valueOf(id), auth.getName())
                || auth.getAuthorities().stream()
                       .anyMatch(a -> "ROLE_SOPORTE".equals(a.getAuthority()));
        return new AuthorizationDecision(permitido);
    }
}

// Enganchado en la cadena con la variable de ruta disponible:
.authorizeHttpRequests(auth -> auth
    .requestMatchers("/pedidos/{id}").access(pedidoAuthorizationManager)
    .anyRequest().authenticated())

Cuando los permisos son por instancia y variables en el tiempo (“Ana puede editar la carpeta 42; Luis solo leerla”), lo que necesitas es una ACL: una tabla (tipo_recurso, id_recurso, sujeto, permiso) consultada en la propia query, o el módulo spring-security-acl. Antes de adoptarlo, mide: en el 90% de los casos basta una columna de propietario y un par de roles, y una ACL mal diseñada es una fuente inagotable de consultas N+1.

3.7 CSRF: qué es y cuándo hace falta de verdad

CSRF (Cross-Site Request Forgery) explota que el navegador adjunta las cookies de un dominio automáticamente, sin importar quién originó la petición. Si tu sesión vive en una cookie, una página maliciosa puede provocar acciones en tu nombre sin leer nada de tu sitio.

ANATOMÍA DE UN ATAQUE CSRF

 1. Ana inicia sesión en banco.com  →  el navegador guarda la cookie JSESSIONID.
 2. Ana visita, en otra pestaña, un foro donde alguien ha publicado esto:

      <form action="https://banco.com/transferencia" method="POST">
        <input type="hidden" name="destino" value="ES00-atacante">
        <input type="hidden" name="importe" value="5000">
      </form>
      <script>document.forms[0].submit()</script>

 3. El navegador envía el POST a banco.com  Y ADJUNTA LA COOKIE de Ana.
 4. banco.com ve una sesión válida  →  ejecuta la transferencia.

 El atacante NUNCA lee la respuesta (la política del mismo origen se lo impide).
 No necesita leerla: le basta con que el EFECTO ocurra.

DEFENSA (token sincronizador): el servidor exige, en cada petición que cambia estado,
un valor secreto que SOLO puede conocer quien haya podido LEER una página del sitio.
El atacante puede provocar la petición, pero no puede leer nada → no tiene el token.

// ✅ Web con sesión: CSRF ACTIVADO (es el valor por defecto: no lo toques).
// Thymeleaf inserta el campo _csrf automáticamente en los <form th:action>.

// ✅ SPA que se autentica con cookie y lee el token del DOM/cookie:
http.csrf(csrf -> csrf
        .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())  // cookie XSRF-TOKEN legible
        .csrfTokenRequestHandler(new SpaCsrfTokenRequestHandler()));
// El cliente lee la cookie XSRF-TOKEN y la reenvía en la cabecera X-XSRF-TOKEN.
// ⚠️ Spring Security 6 usa por defecto XorCsrfTokenRequestAttributeHandler (protección contra
//    BREACH) y carga el token de forma diferida. Para SPAs, la documentación oficial describe
//    exactamente este SpaCsrfTokenRequestHandler; si copias una receta de SS5 verás 403 fantasma.

// ✅ API stateless con Bearer: desactivar CSRF es CORRECTO y no es una excusa.
http.csrf(AbstractHttpConfigurer::disable)
    .sessionManagement(s -> s.sessionCreationPolicy(SessionCreationPolicy.STATELESS));

// ⚠️ Si desactivas CSRF en toda la aplicación "porque daba 403 en Postman" y la parte web usa
//    sesión, acabas de introducir una vulnerabilidad real. Sepáralo en dos cadenas (sección 3.4).

3.8 CORS: lo que casi todo el mundo configura mal

Primero, el malentendido de base: CORS no es una protección de tu servidor, es una relajación controlada de la política del mismo origen del navegador. Un curl o un script en Python ignoran CORS por completo. Abrir CORS no “abre” tu API a los atacantes (ya estaba abierta a herramientas no-navegador); lo que hace es permitir que páginas web de otros orígenes lean tus respuestas usando las credenciales del usuario.

// ✅ Configuración correcta y explícita
@Bean
CorsConfigurationSource fuenteCors() {
    CorsConfiguration config = new CorsConfiguration();
    config.setAllowedOrigins(List.of("https://app.miempresa.com",
                                     "https://admin.miempresa.com"));   // lista cerrada
    config.setAllowedMethods(List.of("GET", "POST", "PUT", "PATCH", "DELETE"));
    config.setAllowedHeaders(List.of("Authorization", "Content-Type", "X-XSRF-TOKEN"));
    config.setExposedHeaders(List.of("X-Total-Count", "Location"));      // lo que el JS puede LEER
    config.setAllowCredentials(true);                                    // solo si usas cookies
    config.setMaxAge(Duration.ofMinutes(30));                            // cachea el preflight
    var fuente = new UrlBasedCorsConfigurationSource();
    fuente.registerCorsConfiguration("/api/**", config);
    return fuente;
}
// Y engánchalo en la cadena (si no, el CorsFilter de Security no se entera):
http.cors(cors -> cors.configurationSource(fuenteCors()));

3.9 Cabeceras de seguridad, sesión y errores

Gestión de sesión

FIJACIÓN DE SESIÓN (session fixation) — por qué Spring cambia el id al autenticarse

 1. El atacante obtiene un JSESSIONID válido (basta con visitar el sitio) → "SID=ABC".
 2. Consigue que la víctima use ESE id (enlace con el id en la URL, cookie inyectada
    desde un subdominio, XSS…).
 3. La víctima se autentica. Si el servidor CONSERVA el id ABC, ahora ABC está
    asociado a una sesión autenticada… y el atacante también tiene ABC.

 DEFENSA: al autenticarse, se genera un id NUEVO (changeSessionId, por defecto en
 Spring Security desde la versión 4 sobre Servlet 3.1+). El id antiguo queda inútil.
 Complementos: nunca el id en la URL (DisableEncodeUrlFilter), cookie HttpOnly+Secure.

# Sesión en Redis: obligatorio si escalas horizontalmente sin sesiones "pegajosas".
# Dependencia: spring-session-data-redis
spring:
  session:
    store-type: redis
    timeout: 30m
    redis:
      namespace: pedidos:sesion
      flush-mode: on-save
  data:
    redis:
      host: ${REDIS_HOST}
      ssl:
        enabled: true
server:
  servlet:
    session:
      cookie:
        name: SESION            # renombrar oculta la tecnología (mínima ofuscación, gratis)
        http-only: true
        secure: true
        same-site: lax

Con sesión centralizada, el logout es real e inmediato (borras la entrada de Redis) y puedes invalidar todas las sesiones de un usuario tras un cambio de contraseña o un incidente. Es, de hecho, la principal ventaja de las sesiones frente al JWT.

Excepciones y respuestas de error que no filtran información

// ✅ 401 para API: sin redirección a /login, con la cabecera correcta y sin detalles
@Component
public class PuntoEntradaApi implements AuthenticationEntryPoint {

    private final ObjectMapper mapper;

    @Override
    public void commence(HttpServletRequest req, HttpServletResponse res,
                         AuthenticationException ex) throws IOException {
        // AUDITA el detalle en el log (con traceId), NO en la respuesta
        log.warn("auth_fallida ruta={} ip={} tipo={}", req.getRequestURI(),
                 req.getRemoteAddr(), ex.getClass().getSimpleName());

        res.setStatus(HttpStatus.UNAUTHORIZED.value());
        res.setHeader(HttpHeaders.WWW_AUTHENTICATE, "Bearer realm=\"pedidos\"");
        res.setContentType(MediaType.APPLICATION_PROBLEM_JSON_VALUE);
        var problema = ProblemDetail.forStatusAndDetail(HttpStatus.UNAUTHORIZED,
                "Credenciales ausentes o no válidas");     // mensaje GENÉRICO, RFC 9457
        problema.setProperty("traceId", MDC.get("traceId"));
        mapper.writeValue(res.getOutputStream(), problema);
    }
}

// ✅ 403 con el mismo criterio
@Component
public class ManejadorDenegado implements AccessDeniedHandler {
    @Override
    public void handle(HttpServletRequest req, HttpServletResponse res,
                       AccessDeniedException ex) throws IOException {
        log.warn("acceso_denegado usuario={} ruta={} ",
                 SecurityContextHolder.getContext().getAuthentication().getName(),
                 req.getRequestURI());
        res.setStatus(HttpStatus.FORBIDDEN.value());
        res.setContentType(MediaType.APPLICATION_PROBLEM_JSON_VALUE);
        res.getWriter().write("""
                {"type":"about:blank","title":"Forbidden","status":403,
                 "detail":"No tienes permiso para esta operación"}""");
    }
}

// ❌ Lo que NUNCA debe salir al cliente
// {"error":"org.postgresql.util.PSQLException: ERROR: relation \\"pedido\\" does not exist
//  ... at com.miempresa.PedidoRepository.java:87 ... Hibernate 6.4.1 ... PostgreSQL 15.2"}
//   → versiones, esquema, rutas internas y un mapa de tu arquitectura, gratis para el atacante.

3.10 Probar la seguridad (si no hay test, no existe)

// Dependencia: org.springframework.security:spring-security-test (scope test)
// Imports estáticos clave:
// SecurityMockMvcRequestPostProcessors.{csrf, jwt, user, httpBasic, oauth2Login}
// SecurityMockMvcResultMatchers.{authenticated, unauthenticated}

@WebMvcTest(PedidoController.class)
@Import(ConfiguracionSeguridad.class)          // sin esto, la cadena real no se aplica
class PedidoControllerSeguridadTest {

    @Autowired MockMvc mvc;
    @MockitoBean ServicioPedidos servicio;

    @Test
    void anonimo_recibe_401() throws Exception {
        mvc.perform(get("/api/pedidos/1"))
           .andExpect(status().isUnauthorized());
    }

    @Test
    @WithMockUser(username = "ana", roles = "USER")          // crea el Authentication en el contexto
    void usuario_sin_permiso_recibe_403() throws Exception {
        mvc.perform(delete("/api/pedidos/1").with(csrf()))   // .with(csrf()) si la cadena lo exige
           .andExpect(status().isForbidden());
    }

    @Test
    void resource_server_valida_scopes() throws Exception {
        mvc.perform(get("/api/pedidos")
                .with(jwt().jwt(j -> j.claim("scope", "pedidos.read")
                                      .subject("12345678A")
                                      .claim("roles", List.of("USER")))))
           .andExpect(status().isOk());

        mvc.perform(post("/api/pedidos")
                .with(jwt().jwt(j -> j.claim("scope", "pedidos.read")))   // le falta pedidos.write
                .contentType(MediaType.APPLICATION_JSON).content("{}"))
           .andExpect(status().isForbidden());
    }

    @Test
    @WithMockUser("ana")
    void no_puede_ver_pedidos_de_otro() throws Exception {          // el test que evita el IDOR
        given(servicio.ver(99L)).willThrow(new PedidoNoEncontrado(99L));
        mvc.perform(get("/api/pedidos/99"))
           .andExpect(status().isNotFound());                        // 404, no 403: no confirma existencia
    }

    @Test
    void cabeceras_de_seguridad_presentes() throws Exception {
        mvc.perform(get("/api/publico/ping"))
           .andExpect(header().string("X-Content-Type-Options", "nosniff"))
           .andExpect(header().exists("Content-Security-Policy"));
    }
}

// Para la capa de servicio (@PreAuthorize), test de integración con el contexto real:
@SpringBootTest
class ServicioPedidosSeguridadTest {
    @Autowired ServicioPedidos servicio;

    @Test
    @WithMockUser(roles = "USER")
    void cancelarTodos_exige_admin() {
        assertThatThrownBy(() -> servicio.cancelarTodos(LocalDate.now()))
                .isInstanceOf(AccessDeniedException.class);
    }
}

4. Autenticación con tokens: sesión, JWT y refresh

4.1 Sesión con cookie vs JWT: la tabla honesta

4.2 Anatomía de un JWT

Un JWS compacto son TRES bloques en Base64URL separados por puntos:

  eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjIwMjYtMDEifQ      ← header
  .eyJpc3MiOiJodHRwczovL2F1dGgubWllbXByZXNhLmNvbSIsInN1YiI6…      ← payload (claims)
  .Kx7fQ9mB2rT8vN1wLpZ3sYcH0dJ4gE6uA5iO7nQ2xR8                    ← firma

┌─ HEADER ────────────────────────────────────────────────────────────────────┐
│ { "alg": "RS256",      ← algoritmo de firma                                 │
│   "typ": "JWT",                                                             │
│   "kid": "2026-01" }   ← qué clave del JWKS usar (permite rotar sin cortes)  │
└─────────────────────────────────────────────────────────────────────────────┘
┌─ PAYLOAD ───────────────────────────────────────────────────────────────────┐
│ { "iss": "https://auth.miempresa.com",   ← emisor: ¿es MI emisor?           │
│   "sub": "12345678A",                    ← sujeto: el usuario               │
│   "aud": ["pedidos-api"],                ← audiencia: ¿este token es PARA MÍ?│
│   "exp": 1774951200,                     ← expira (epoch en SEGUNDOS)       │
│   "iat": 1774950300,                     ← emitido en                       │
│   "nbf": 1774950300,                     ← no válido antes de               │
│   "jti": "b3f1…",                        ← id único: permite revocar ESTE   │
│   "scope": "pedidos.read pedidos.write", ← permisos delegados (OAuth2)       │
│   "roles": ["USER"] }                    ← claim propio                     │
└─────────────────────────────────────────────────────────────────────────────┘
┌─ FIRMA ─────────────────────────────────────────────────────────────────────┐
│ RSASSA-PKCS1-v1_5( SHA256( base64url(header) + "." + base64url(payload) ) ) │
└─────────────────────────────────────────────────────────────────────────────┘

⚠️ EL PAYLOAD NO ESTÁ CIFRADO. Base64 NO es cifrado: cualquiera con el token lee
   todo su contenido (pruébalo con `echo … | base64 -d`, o en jwt.io con un token
   de PRUEBA, nunca con uno real). La firma garantiza INTEGRIDAD, no confidencialidad.
   → No metas nunca datos personales innecesarios, direcciones, DNI o secretos.
   → Si de verdad necesitas confidencialidad del contenido, existe JWE (cifrado),
     pero suele ser más simple usar un token OPACO y consultar /introspect.

4.3 Validación correcta (aquí es donde se cometen los fallos)

“Verifico la firma” es menos de la mitad del trabajo. Estas son las comprobaciones obligatorias y los ataques que evita cada una:

# ✅ La forma correcta y aburrida: que lo haga Spring Boot por ti.
spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          # Descubre jwks_uri vía /.well-known/openid-configuration y valida iss, exp, nbf y firma
          issuer-uri: https://auth.miempresa.com/realms/pedidos
          audiences: pedidos-api           # ← Spring Boot 3.1+: valida aud. NO LO OLVIDES.
          # authorization-server-metadata (alternativa) o jwk-set-uri si no hay discovery

// Cuando necesitas control fino (validadores adicionales, claves propias, algoritmo fijo)
@Bean
JwtDecoder jwtDecoder(@Value("${jwt.issuer}") String emisor,
                      @Value("${jwt.jwks-uri}") String jwksUri) {

    NimbusJwtDecoder decoder = NimbusJwtDecoder
            .withJwkSetUri(jwksUri)
            .jwsAlgorithms(algs -> { algs.clear(); algs.add(SignatureAlgorithm.RS256); })  // lista blanca
            .build();

    OAuth2TokenValidator<Jwt> porDefecto = JwtValidators.createDefaultWithIssuer(emisor); // exp, nbf, iss

    OAuth2TokenValidator<Jwt> audiencia = new JwtClaimValidator<List<String>>(
            JwtClaimNames.AUD, aud -> aud != null && aud.contains("pedidos-api"));

    OAuth2TokenValidator<Jwt> noRevocado = jwt -> listaRevocacion.contiene(jwt.getId())
            ? OAuth2TokenValidatorResult.failure(
                  new OAuth2Error("invalid_token", "Token revocado", null))
            : OAuth2TokenValidatorResult.success();

    decoder.setJwtValidator(new DelegatingOAuth2TokenValidator<>(
            porDefecto, audiencia, noRevocado));
    return decoder;
}

// ❌ Lo que se ve en tutoriales y NO debes copiar
// 1) Decodificar sin verificar, "solo para leer el usuario":
String sub = new String(Base64.getUrlDecoder().decode(token.split("\\.")[1]));  // ¡sin firma!
// 2) Aceptar el algoritmo que diga el token (API antigua sin fijar algoritmo).
// 3) Escribir tu propio validador de JWT "porque es fácil": no lo es. Usa Nimbus/Spring.

4.4 El problema de la revocación y sus tres soluciones

Un JWT es una afirmación firmada con fecha de caducidad. Nadie puede “desfirmarla”. Si despides a alguien, si un token se filtra o si un usuario cambia su contraseña, el token sigue siendo matemáticamente válido hasta su exp. Las soluciones reales:

1. Access tokens de vida muy corta + refresh token. El access token vive 5–15 minutos y no se comprueba contra ningún estado; el refresh token vive días, es opaco y se valida contra la base de datos del emisor, donde sí puedes revocarlo. La ventana de exposición es igual a la vida del access token. Es la solución por defecto.
2. Lista de revocación (denylist) por jti. Guardas en Redis los identificadores revocados con TTL igual a su exp restante. Recuperas la revocación inmediata a cambio de una consulta por petición: has reintroducido el estado que querías evitar, pero solo para los casos excepcionales (la lista es pequeña).
3. Versión de credenciales. El token incluye cver: 7; el usuario tiene una columna credential_version. Al cambiar la contraseña o revocar accesos, incrementas la versión y todos los tokens anteriores dejan de validar. Es barato (una consulta cacheable) y muy efectivo para el caso “invalidar todas las sesiones de este usuario”.

4.5 ¿Dónde guardo el token en el cliente?

4.6 Refresh tokens y detección de reutilización

ROTACIÓN DE REFRESH TOKENS CON DETECCIÓN DE REUSO (reuse detection)

 Cliente                                   Authorization Server
   │                                                │
   │─ POST /token (grant=refresh, RT1) ────────────►│  RT1 válido → lo MARCA COMO USADO
   │◄─ { access_token: AT2, refresh_token: RT2 } ───│  y emite el par (AT2, RT2)
   │                                                │  familia: RT1 → RT2 (misma cadena)
   │─ POST /token (grant=refresh, RT2) ────────────►│  ok → RT3
   │                                                │
   │  ⚠️ ALGUIEN usa RT1 otra vez (lo había robado)  │
   │─ POST /token (grant=refresh, RT1) ────────────►│  RT1 YA ESTABA USADO
   │◄─ 400 invalid_grant ──────────────────────────│  → REVOCA TODA LA FAMILIA
   │                                                │     (RT1, RT2, RT3…) y audita
   │  Resultado: tanto el atacante como el          │
   │  usuario legítimo tienen que reautenticarse.   │
   │  Molesto, pero has DETECTADO y CORTADO el robo.│

Sin rotación, un refresh token robado da acceso silencioso durante semanas.
Con rotación + detección de reuso, el segundo uso delata el robo.
Requisitos: almacenar los RT (su hash) con estado usado/no usado y su familia.
Keycloak, Spring Authorization Server, Auth0 y Okta lo implementan de serie.

4.7 Emitir y validar JWT en Spring Boot 3

// Dependencia: spring-boot-starter-oauth2-resource-server (trae Nimbus JOSE + JWT)
@Configuration
public class ConfiguracionJwt {

    /** Par de claves RSA. En producción: cargado de un KMS o de un keystore montado, NUNCA generado al
     *  arrancar (si se genera al arrancar, cada réplica firma con una clave distinta y cada reinicio
     *  invalida todos los tokens emitidos). */
    @Bean
    RSAKey claveFirma(@Value("${jwt.key-id}") String kid,
                      KeyStore keyStore,
                      @Value("${jwt.key-alias}") String alias,
                      @Value("${jwt.key-password}") char[] password) throws Exception {
        var privada = (RSAPrivateKey) keyStore.getKey(alias, password);
        var certificado = (X509Certificate) keyStore.getCertificate(alias);
        return new RSAKey.Builder((RSAPublicKey) certificado.getPublicKey())
                .privateKey(privada)
                .keyID(kid)                       // aparecerá como "kid" en el header y en el JWKS
                .algorithm(JWSAlgorithm.RS256)
                .build();
    }

    @Bean
    JWKSource<SecurityContext> jwkSource(RSAKey clave) {
        // Publica SOLO la parte pública en /oauth2/jwks para que otros servicios validen
        return new ImmutableJWKSet<>(new JWKSet(clave));
    }

    @Bean
    JwtEncoder jwtEncoder(JWKSource<SecurityContext> jwks) {
        return new NimbusJwtEncoder(jwks);
    }

    @Bean
    JwtDecoder jwtDecoder(RSAKey clave, @Value("${jwt.issuer}") String emisor) throws Exception {
        NimbusJwtDecoder decoder = NimbusJwtDecoder
                .withPublicKey(clave.toRSAPublicKey())
                .signatureAlgorithm(SignatureAlgorithm.RS256)     // fijado: sin alg confusion
                .build();
        decoder.setJwtValidator(new DelegatingOAuth2TokenValidator<>(
                JwtValidators.createDefaultWithIssuer(emisor),
                new JwtClaimValidator<List<String>>(JwtClaimNames.AUD,
                        aud -> aud != null && aud.contains("pedidos-api"))));
        return decoder;
    }
}

@Service
public class EmisorTokens {

    private static final Duration VIDA_ACCESS = Duration.ofMinutes(10);   // corta: la revocación depende de esto
    private static final Duration VIDA_REFRESH = Duration.ofDays(14);

    private final JwtEncoder encoder;
    private final RSAKey clave;
    private final RepositorioRefreshTokens refrescos;

    public ParTokens emitir(UsuarioAplicacion usuario) {
        Instant ahora = Instant.now();

        JwtClaimsSet claims = JwtClaimsSet.builder()
                .issuer("https://auth.miempresa.com")
                .subject(usuario.getUsername())
                .audience(List.of("pedidos-api"))
                .issuedAt(ahora)
                .notBefore(ahora)
                .expiresAt(ahora.plus(VIDA_ACCESS))
                .id(UUID.randomUUID().toString())               // jti: permite revocar ESTE token
                .claim("roles", usuario.getAuthorities().stream()
                        .map(GrantedAuthority::getAuthority).toList())
                .claim("cver", usuario.getVersionCredenciales()) // versión de credenciales
                .build();

        JwsHeader header = JwsHeader.with(SignatureAlgorithm.RS256)
                .keyId(clave.getKeyID())                         // para que el verificador elija la clave
                .build();

        String accessToken = encoder.encode(JwtEncoderParameters.from(header, claims)).getTokenValue();

        // El refresh token NO es un JWT: es un valor opaco de alta entropía, guardado HASHEADO.
        byte[] bytes = new byte[32];
        new SecureRandom().nextBytes(bytes);
        String refresh = Base64.getUrlEncoder().withoutPadding().encodeToString(bytes);
        refrescos.guardar(new RefreshToken(
                sha256(refresh),                     // guardamos el HASH, no el token
                usuario.getUsername(),
                ahora.plus(VIDA_REFRESH),
                UUID.randomUUID()));                 // id de familia, para la detección de reuso

        return new ParTokens(accessToken, refresh, VIDA_ACCESS.toSeconds());
    }
}

Resource Server: convertir claims en GrantedAuthority

// Por defecto Spring toma el claim "scope" (o "scp") y prefija las authorities con SCOPE_
//   scope: "pedidos.read"  →  authority "SCOPE_pedidos.read"  →  hasAuthority("SCOPE_pedidos.read")
// Si tus roles vienen en otro claim (o anidados, como en Keycloak), necesitas un convertidor.

@Bean
JwtAuthenticationConverter convertidorJwt() {
    var scopes = new JwtGrantedAuthoritiesConverter();      // mantiene SCOPE_* a partir de "scope"

    JwtAuthenticationConverter convertidor = new JwtAuthenticationConverter();
    convertidor.setPrincipalClaimName("sub");
    convertidor.setJwtGrantedAuthoritiesConverter(jwt -> {
        Collection<GrantedAuthority> autoridades = new ArrayList<>(scopes.convert(jwt));

        // Roles de Keycloak: { "realm_access": { "roles": ["USER","ADMIN"] } }
        Map<String, Object> realmAccess = jwt.getClaimAsMap("realm_access");
        if (realmAccess != null && realmAccess.get("roles") instanceof Collection<?> roles) {
            roles.stream()
                 .map(String::valueOf)
                 .map(rol -> new SimpleGrantedAuthority("ROLE_" + rol))   // prefijo para hasRole()
                 .forEach(autoridades::add);
        }
        return autoridades;
    });
    return convertidor;
}

@Bean
SecurityFilterChain apiConversion(HttpSecurity http, JwtAuthenticationConverter convertidor)
        throws Exception {
    return http
        .securityMatcher("/api/**")
        .csrf(AbstractHttpConfigurer::disable)
        .sessionManagement(s -> s.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
        .authorizeHttpRequests(auth -> auth
            .requestMatchers(HttpMethod.GET,  "/api/pedidos/**").hasAuthority("SCOPE_pedidos.read")
            .requestMatchers(HttpMethod.POST, "/api/pedidos").hasAuthority("SCOPE_pedidos.write")
            .requestMatchers("/api/admin/**").hasRole("ADMIN")          // busca ROLE_ADMIN
            .anyRequest().authenticated())
        .oauth2ResourceServer(oauth -> oauth.jwt(jwt -> jwt.jwtAuthenticationConverter(convertidor)))
        .build();
}

5. OAuth 2 / OAuth 2.1 y OpenID Connect

5.1 El problema que resuelve (y el que no)

Imagina 2008: una web quiere mostrar tus fotos de otro servicio. La única forma era que le dieras tu usuario y tu contraseña. Consecuencias: la web tenía acceso total (podía borrar tu cuenta), guardaba tu contraseña en su base de datos, no podías revocarle el acceso sin cambiar la contraseña y no podías limitar qué hacía. Ese antipatrón tenía nombre propio: el password antipattern.

OAuth 2 es un protocolo de delegación de autorización: permite que una aplicación obtenga acceso limitado y revocable a unos recursos, en nombre del usuario, sin conocer nunca sus credenciales.

5.2 Los cuatro roles

5.3 Authorization Code + PKCE: el flujo correcto para casi todo

AUTHORIZATION CODE + PKCE  (RFC 7636) — para SPA, móvil y web con servidor

  Antes de empezar, el cliente genera en local:
     code_verifier  = 43–128 caracteres aleatorios de SecureRandom
     code_challenge = BASE64URL( SHA-256( code_verifier ) )        method = S256

 Navegador/App        Authorization Server (Keycloak)      Resource Server (API)
      │                          │                                  │
 (1)  │ GET /authorize?          │                                  │
      │   response_type=code     │                                  │
      │   client_id=spa-pedidos  │                                  │
      │   redirect_uri=https://app.miempresa.com/callback           │
      │   scope=openid pedidos.read                                 │
      │   state=xyz789           │   ← anti-CSRF del propio flujo    │
      │   nonce=abc123           │   ← liga el id_token a ESTA sesión│
      │   code_challenge=E9Me…   │                                  │
      │   code_challenge_method=S256                                │
      │─────────────────────────►│                                  │
      │                          │                                  │
 (2)  │  El AS autentica al USUARIO (contraseña + MFA) y pide       │
      │  consentimiento. La contraseña NUNCA pasa por el cliente.   │
      │                          │                                  │
 (3)  │◄─ 302 a redirect_uri?code=SplxlOB…&state=xyz789 ───────────│
      │   El cliente VERIFICA que state coincide con el que envió.  │
      │                          │                                  │
 (4)  │ POST /token              │                                  │
      │   grant_type=authorization_code                             │
      │   code=SplxlOB…          │                                  │
      │   redirect_uri=…         │   ← debe ser IDÉNTICO al de (1)   │
      │   client_id=spa-pedidos  │                                  │
      │   code_verifier=dBjftJ…  │   ← el AS calcula SHA-256 y lo    │
      │─────────────────────────►│      compara con code_challenge   │
      │                          │                                  │
 (5)  │◄─ { access_token, id_token, refresh_token, expires_in } ────│
      │   (canal directo, POST, no pasa por la barra de direcciones) │
      │                          │                                  │
 (6)  │ GET /api/pedidos                                            │
      │ Authorization: Bearer <access_token>                        │
      │────────────────────────────────────────────────────────────►│
      │                          │◄── GET /.well-known/jwks.json ───│ (una vez, cacheado)
      │◄─ 200 [ … ] ───────────────────────────────────────────────│

¿QUÉ APORTA PKCE? El "code" viaja por la barra de direcciones y por el historial. En móvil
puede ser interceptado por otra app registrada en el mismo esquema de URL. PKCE hace que el
code sea INÚTIL sin el code_verifier, que solo existe en la memoria del cliente legítimo.
→ En OAuth 2.1 PKCE es OBLIGATORIO para TODOS los clientes, también los confidenciales.

state vs nonce (pregunta habitual):
  · state → protege contra CSRF en el propio flujo: garantiza que la respuesta corresponde
            a una petición que TÚ iniciaste. Es de OAuth 2.
  · nonce → va dentro del id_token y garantiza que ese id_token se emitió para ESTA
            solicitud concreta (anti-replay). Es de OpenID Connect.

5.4 Client Credentials: servicio a servicio

CLIENT CREDENTIALS  — no hay usuario, la identidad ES la aplicación

  Servicio facturación                Authorization Server           API pedidos
        │                                    │                            │
        │─ POST /token ─────────────────────►│                            │
        │   grant_type=client_credentials    │                            │
        │   client_id=facturacion            │                            │
        │   client_secret=•••  (o mTLS,      │                            │
        │     o private_key_jwt: mejor)      │                            │
        │   scope=pedidos.read               │                            │
        │◄─ { access_token, expires_in } ────│                            │
        │                                    │                            │
        │─ GET /api/pedidos  Bearer … ──────────────────────────────────►│
        │◄─ 200 ───────────────────────────────────────────────────────── │

· No hay redirect_uri, ni consentimiento, ni refresh token (se pide otro y punto).
· El "sub" del token es la APLICACIÓN, no una persona → los logs de auditoría deben
  distinguir "actor=servicio:facturacion" de "actor=usuario:12345678A".
· Autenticación del cliente, de peor a mejor: client_secret_post < client_secret_basic
  < private_key_jwt < tls_client_auth (mTLS). Con mTLS no hay secreto que filtrar.
· Cachea el token hasta su expiración menos un margen; NO pidas uno por petición.

# Cliente de Client Credentials en Spring Boot (para llamar a otra API)
spring:
  security:
    oauth2:
      client:
        registration:
          facturacion:
            provider: keycloak
            client-id: facturacion
            client-secret: ${OAUTH_CLIENT_SECRET}      # de un secreto de la plataforma
            authorization-grant-type: client_credentials
            scope: pedidos.read
        provider:
          keycloak:
            issuer-uri: https://auth.miempresa.com/realms/pedidos

// Y el cliente HTTP que adjunta el token automáticamente y lo refresca solo:
@Bean
RestClient clientePedidos(RestClient.Builder builder,
                          OAuth2AuthorizedClientManager gestor) {
    var interceptor = new OAuth2ClientHttpRequestInterceptor(gestor);
    interceptor.setClientRegistrationIdResolver(request -> "facturacion");
    return builder
            .baseUrl("https://pedidos.interno.miempresa.com")
            .requestInterceptor(interceptor)
            .build();
}

// ❌ Lo que NO debes hacer: propagar el token del USUARIO a otro servicio "porque funciona".
//    Ese token tiene aud=pedidos-api; si facturacion-api lo acepta, está saltándose la
//    validación de audiencia y cualquiera con un token de pedidos entra en facturación.
//    Si necesitas actuar en nombre del usuario, usa Token Exchange (RFC 8693).

5.5 Device Code y Refresh Token

DEVICE AUTHORIZATION GRANT (RFC 8628) — televisores, CLI, IoT: sin teclado o sin navegador

   Dispositivo (o CLI)                Authorization Server            Móvil del usuario
        │                                    │                              │
        │─ POST /device_authorization ──────►│                              │
        │◄─ { device_code, user_code: "WDJB-MJHT",                          │
        │     verification_uri: "https://auth…/device",                     │
        │     interval: 5, expires_in: 600 } │                              │
        │                                    │                              │
        │  Muestra en pantalla:              │                              │
        │  "Ve a auth.miempresa.com/device   │                              │
        │   e introduce WDJB-MJHT"           │◄── el usuario se autentica ──│
        │                                    │    y teclea el código        │
        │─ POST /token (device_code) ───────►│                              │
        │◄─ 400 authorization_pending ───────│  (sondeo cada `interval` s)   │
        │─ POST /token (device_code) ───────►│                              │
        │◄─ { access_token, refresh_token } ─│  ¡aprobado!                   │

Ejemplo cotidiano: `az login`, `gh auth login`, activar Netflix en la tele.

REFRESH TOKEN GRANT — renovar sin volver a molestar al usuario
        │─ POST /token  grant_type=refresh_token&refresh_token=… ──────────►│
        │◄─ { access_token nuevo, refresh_token nuevo (rotación) } ─────────│
  · Los clientes PÚBLICOS deben usar rotación con detección de reuso (ver 4.6).
  · El refresh token es la credencial de larga vida: trátalo como una contraseña.

5.6 Flujos obsoletos y por qué

5.7 Scopes, roles y permisos: tres capas distintas

Consejo de diseño: mete en el token lo estable y pequeño (identidad y scopes) y resuelve en la aplicación lo fino y cambiante (permisos por recurso). Un token con 200 permisos dentro es enorme, se queda obsoleto en el momento en que se emite y acaba superando el límite de tamaño de cabeceras de algún proxy. Y sobre todo: autoriza siempre por permiso, no por rol, en el código (hasAuthority("pedidos:cancelar")), para que cambiar quién tiene un permiso no exija tocar código.

5.8 OpenID Connect: autenticación de verdad

OIDC añade a OAuth 2 tres piezas: el id_token (un JWT con la identidad del usuario, con reglas de validación obligatorias), el endpoint /userinfo (más datos del perfil, con el access token) y el discovery (/.well-known/openid-configuration) que hace que un cliente se configure con una sola URL.

# Discovery: la URL que te ahorra configurar diez cosas a mano
curl -s https://auth.miempresa.com/realms/pedidos/.well-known/openid-configuration | jq
# {
#   "issuer": "https://auth.miempresa.com/realms/pedidos",
#   "authorization_endpoint": ".../protocol/openid-connect/auth",
#   "token_endpoint":         ".../protocol/openid-connect/token",
#   "userinfo_endpoint":      ".../protocol/openid-connect/userinfo",
#   "jwks_uri":               ".../protocol/openid-connect/certs",
#   "end_session_endpoint":   ".../protocol/openid-connect/logout",
#   "introspection_endpoint": ".../protocol/openid-connect/token/introspect",
#   "code_challenge_methods_supported": ["plain","S256"],
#   "id_token_signing_alg_values_supported": ["RS256","ES256"],
#   "grant_types_supported": ["authorization_code","refresh_token","client_credentials"]
# }
# Es lo que Spring Boot consume con spring.security.oauth2.*.issuer-uri

5.9 Keycloak en 15 minutos y conectarlo a Spring

# 1) Arrancar Keycloak para desarrollo (start-dev: sin TLS, con BD en memoria H2)
docker run -d --name keycloak -p 8081:8080 \
  -e KC_BOOTSTRAP_ADMIN_USERNAME=admin \
  -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin \
  quay.io/keycloak/keycloak:26.0 start-dev
# En versiones anteriores a 26 las variables eran KEYCLOAK_ADMIN / KEYCLOAK_ADMIN_PASSWORD.
# ⚠️ start-dev NO es apto para producción: sin HTTPS, sin caché distribuida, con H2.
#    En producción: `start` con --hostname, --db=postgres y TLS terminado en el ingress.

# 2) Consola de administración → http://localhost:8081  (admin/admin)

# 3) Lo que hay que crear (por la interfaz o con kcadm.sh):
#    a) REALM        "pedidos"                       ← frontera de aislamiento: usuarios, roles, clientes
#    b) ROLES de realm: USER, ADMIN, SOPORTE
#    c) CLIENTE "spa-pedidos"   (público, para la SPA)
#         Client authentication: OFF        ← cliente público: no puede guardar secreto
#         Standard flow: ON  ·  Direct access grants: OFF   ← ¡desactiva el password grant!
#         Valid redirect URIs: https://app.miempresa.com/callback  (NUNCA "*")
#         Valid post logout redirect URIs: https://app.miempresa.com/
#         Web origins: https://app.miempresa.com   (NUNCA "*")
#         PKCE: Advanced → Proof Key for Code Exchange Code Challenge Method = S256
#    d) CLIENTE "pedidos-api"   (audiencia de los tokens; sin flujos activos)
#    e) CLIENTE "facturacion"   (confidencial, Service accounts roles: ON → client_credentials)
#    f) USUARIO de prueba + contraseña + asignación de roles
#    g) MAPPER de audiencia en spa-pedidos:
#         Dedicated scopes → Add mapper → By configuration → Audience
#         Included Client Audience = pedidos-api      ← para que aud contenga tu API

# 4) Comprobar los tokens que emite (solo en desarrollo)
curl -s -X POST http://localhost:8081/realms/pedidos/protocol/openid-connect/token \
  -d grant_type=client_credentials \
  -d client_id=facturacion -d client_secret=$SECRETO | jq -r .access_token
# Pega el resultado en jwt.io SOLO si es un token de desarrollo. Nunca uno de producción.

# 5) Exportar la configuración del realm para versionarla en git (infraestructura como código)
docker exec keycloak /opt/keycloak/bin/kc.sh export --dir /tmp/export --realm pedidos
docker cp keycloak:/tmp/export/pedidos-realm.json ./infra/keycloak/

# A) Nuestra API como RESOURCE SERVER (solo valida tokens)
# Dependencia: spring-boot-starter-oauth2-resource-server
spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: http://localhost:8081/realms/pedidos
          audiences: pedidos-api          # imprescindible: sin esto aceptas tokens de otras APIs

---
# B) Una aplicación web como CLIENT (login delegado en Keycloak, sesión propia)
# Dependencia: spring-boot-starter-oauth2-client
spring:
  security:
    oauth2:
      client:
        registration:
          keycloak:
            client-id: web-pedidos
            client-secret: ${OAUTH_CLIENT_SECRET}
            authorization-grant-type: authorization_code
            scope: openid,profile,email,pedidos.read
            redirect-uri: "{baseUrl}/login/oauth2/code/{registrationId}"
        provider:
          keycloak:
            issuer-uri: http://localhost:8081/realms/pedidos
            user-name-attribute: preferred_username

// Cadena de la aplicación cliente: login OIDC + logout federado (RP-Initiated Logout)
@Bean
SecurityFilterChain webOidc(HttpSecurity http, ClientRegistrationRepository registros) throws Exception {
    var logoutHandler = new OidcClientInitiatedLogoutSuccessHandler(registros);
    logoutHandler.setPostLogoutRedirectUri("{baseUrl}/");   // cierra sesión también en Keycloak

    return http
        .authorizeHttpRequests(auth -> auth
            .requestMatchers("/", "/error", "/css/**").permitAll()
            .anyRequest().authenticated())
        .oauth2Login(login -> login.userInfoEndpoint(ui -> ui.oidcUserService(servicioUsuarioOidc())))
        .logout(logout -> logout.logoutSuccessHandler(logoutHandler))
        .build();
}

// Leer la identidad del usuario autenticado por OIDC
@GetMapping("/panel")
public String panel(@AuthenticationPrincipal OidcUser usuario, Model modelo) {
    modelo.addAttribute("nombre", usuario.getFullName());
    modelo.addAttribute("email", usuario.getEmail());
    modelo.addAttribute("sub", usuario.getSubject());
    modelo.addAttribute("expira", usuario.getIdToken().getExpiresAt());
    return "panel";
}

5.10 Propagar la identidad entre microservicios

Los detalles de gateway, malla de servicio y comunicación entre servicios están en módulo 08; el despliegue y las políticas de red, en módulo 09.

5.11 API keys, MFA, passkeys y SSO

API keys: son aceptables en un caso concreto y con condiciones.

• Cuándo sí: integraciones servidor-a-servidor con terceros, donde no hay usuario y montar OAuth2 sería desproporcionado; identificación de tenant para cuotas y facturación.
• Cuándo no: nunca en un cliente que ejecuta en el navegador o en una app móvil (una API key en una app es una API key pública), y nunca como sustituto de la autorización por usuario.
• Condiciones: generada con SecureRandom (≥ 256 bits); guardada hasheada (SHA-256) en tu base de datos; con prefijo identificable (pk_live_…) para poder detectarla con gitleaks; con scopes, restricción por IP y caducidad; rotable sin cortes (dos claves activas); en la cabecera Authorization o una propia, nunca en la query string (queda en logs y en el historial); y con rate limiting por clave.

Por qué las passkeys son el futuro: eliminan el secreto compartido. No hay nada que filtrar en un volcado de base de datos (el servidor solo guarda una clave pública), no hay nada que reutilizar en otro sitio, no hay nada que teclear en una web falsa y no hay nada que el usuario pueda olvidar. Spring Security incorpora soporte de passkeys/WebAuthn desde la versión 6.4 con el DSL webAuthn(), y también one-time tokens para enlaces de acceso por correo.

SSO empresarial: si la organización ya tiene un proveedor de identidad, no inventes nada. Con OIDC lo conectas con issuer-uri. Si el proveedor es antiguo y solo habla SAML 2.0 (muy común en entornos corporativos y en administraciones públicas), Spring Security tiene spring-security-saml2-service-provider: mismo concepto (delegas la autenticación en un IdP), sintaxis XML y metadatos en lugar de JSON y discovery. Migra a OIDC cuando puedas; conviven bien mientras tanto.

6. OWASP Top 10 aplicado a Java y Spring

El OWASP Top 10 no es un estándar de cumplimiento ni una lista exhaustiva: es un documento de concienciación sobre las categorías de riesgo más extendidas, construido con datos reales de cientos de miles de aplicaciones. Para requisitos verificables existe OWASP ASVS; para recetas concretas, las Cheat Sheets.

A01 · Control de acceso roto

Qué es: el usuario hace algo que no debería poder hacer. Incluye IDOR (acceder a un recurso ajeno cambiando el identificador), escalada vertical (usuario → admin), escalada horizontal (usuario A → datos de usuario B), forzado de navegación a endpoints “ocultos”, manipulación de metadatos (cookies, JWT, campos ocultos) y falta de comprobación en operaciones de escritura. Es la categoría número uno y la que más dinero cuesta.

// ❌ VULNERABLE — IDOR en cadena. Los tres endpoints tienen el mismo fallo.
@RestController
@RequestMapping("/pedidos")
public class PedidoControllerVulnerable {

    @GetMapping("/{id}")                                  // GET /pedidos/4712 → pedido de otro cliente
    public PedidoDto ver(@PathVariable Long id) {
        return mapper.aDto(repositorio.findById(id).orElseThrow());
    }

    @GetMapping("/{id}/factura")                          // ¡y su factura en PDF, con su dirección!
    public ResponseEntity<byte[]> factura(@PathVariable Long id) {
        return ResponseEntity.ok(generador.pdf(repositorio.findById(id).orElseThrow()));
    }

    @DeleteMapping("/{id}")                               // y puede CANCELAR pedidos ajenos
    public void cancelar(@PathVariable Long id) {
        servicio.cancelar(id);
    }
}

// EXPLOTACIÓN (resumida y sin herramientas): el usuario legítimo abre su propio pedido, ve
// /pedidos/4711 en la barra de direcciones y prueba 4710, 4712, 4713… Los identificadores
// secuenciales convierten un fallo de autorización en una descarga masiva de la base de datos.
// No hace falta ninguna habilidad técnica: es un bucle de 20 líneas o incluso el navegador a mano.

// ✅ CORREGIDO — la propiedad forma parte de la consulta y el 404 no confirma la existencia
@RestController
@RequestMapping("/pedidos")
public class PedidoController {

    private final RepositorioPedidos repositorio;

    @GetMapping("/{id}")
    public PedidoDto ver(@PathVariable Long id, @AuthenticationPrincipal Jwt jwt) {
        return repositorio.findByIdAndClienteNif(id, jwt.getSubject())
                .map(mapper::aDto)
                .orElseThrow(() -> new PedidoNoEncontrado(id));      // → 404 siempre
    }

    @GetMapping                                                       // listar SOLO lo propio
    public Page<PedidoDto> mios(@AuthenticationPrincipal Jwt jwt,
                                @PageableDefault(size = 20) Pageable pagina) {
        return repositorio.findAllByClienteNif(jwt.getSubject(), pagina).map(mapper::aDto);
    }

    @DeleteMapping("/{id}")
    @PreAuthorize("@guardiaPedidos.puedeCancelar(#id, authentication)")   // segunda barrera
    public void cancelar(@PathVariable Long id) {
        servicio.cancelar(id);
    }
}

Qué aporta Spring: authorizeHttpRequests, @PreAuthorize/@PostAuthorize, AuthorizationManager, derivación de consultas de Spring Data y spring-security-test para los tests.

A02 · Fallos criptográficos

Qué es: datos sensibles expuestos por ausencia de cifrado o por criptografía mal empleada. Antes se llamaba “exposición de datos sensibles”, y se renombró porque el síntoma era la exposición pero la causa es criptográfica.

// ❌ VULNERABLE
@Entity
public class ClienteVulnerable {
    private String numeroTarjeta;        // PAN en claro: incumple PCI-DSS y es una bomba de relojería
    private String password;             // sin hashear, o con MD5
    private String iban;                 // dato financiero en claro
}
// application.yml en el repositorio:
//   spring.datasource.password: Prod2024!      ← secreto versionado para siempre en git
// Cliente HTTP:
HttpClient.newBuilder().sslContext(contextoQueAceptaTodo()).build();   // TLS sin validar
// Cifrado:
Cipher.getInstance("AES/ECB/PKCS5Padding");                           // patrón visible

// ✅ CORREGIDO
@Entity
public class Cliente {
    @Column(name = "password_hash")
    private String passwordHash;                        // {bcrypt}$2a$12$… (sección 2.2)

    @Convert(converter = ConvertidorCifrado.class)      // cifrado a nivel de campo, AES-GCM
    @Column(name = "iban_cifrado")
    private String iban;

    private String tarjetaUltimos4;                     // "4242": suficiente para la interfaz
    private String tarjetaToken;                        // token del PSP. El PAN NO ESTÁ AQUÍ.
}

@Converter
public class ConvertidorCifrado implements AttributeConverter<String, String> {
    private final CifradoCampo cifrado;                 // clave del KMS, IV aleatorio por valor
    @Override public String convertToDatabaseColumn(String claro) {
        return claro == null ? null : cifrado.cifrar(claro.getBytes(UTF_8), CONTEXTO);
    }
    @Override public String convertToEntityAttribute(String bd) {
        return bd == null ? null : new String(cifrado.descifrar(bd, CONTEXTO), UTF_8);
    }
}
// ⚠️ Consecuencia de cifrar un campo: dejas de poder buscar por él con LIKE o índices normales.
//    Si necesitas buscar por igualdad, guarda además un HMAC determinista del valor (blind index).

Mitigaciones: clasifica los datos antes de decidir controles; no almacenes lo que no necesitas (el dato que no guardas no se filtra); TLS obligatorio en tránsito y cifrado en reposo; algoritmos y modos actuales (sección 2); secretos fuera del repositorio; claves en un KMS con rotación.

Qué aporta Spring: PasswordEncoder y DelegatingPasswordEncoder, SSL bundles, AttributeConverter de JPA, spring-cloud-vault / integración con Secrets Manager para secretos.

A03 · Inyección

Qué es: datos no confiables se interpretan como código o como parte de una instrucción. La causa raíz siempre es la misma: mezclar datos con instrucciones. La solución también: separarlos mediante parámetros, y validar con listas blancas lo que no se puede parametrizar.

// ─── 1) SQL con JDBC ────────────────────────────────────────────────────────────
// ❌ VULNERABLE
String sql = "SELECT * FROM usuarios WHERE email = '" + email + "' AND activo = true";
// Con un email que cierre la comilla y añada  OR '1'='1'  la condición se vuelve siempre
// verdadera y devuelve toda la tabla; con más creatividad se llega a otras tablas.

// ✅ CORRECTO: PreparedStatement. El parámetro NUNCA se interpreta como SQL.
var consulta = "SELECT id, email FROM usuarios WHERE email = ? AND activo = true";
jdbcTemplate.query(consulta, filaMapper, email);

// ─── 2) JPA / JPQL ──────────────────────────────────────────────────────────────
// ❌ VULNERABLE — que sea JPA no te salva si concatenas
em.createQuery("SELECT p FROM Pedido p WHERE p.cliente.nif = '" + nif + "'").getResultList();

// ✅ CORRECTO: parámetros nombrados
em.createQuery("SELECT p FROM Pedido p WHERE p.cliente.nif = :nif", Pedido.class)
  .setParameter("nif", nif).getResultList();

// ✅ Y en Spring Data
@Query("SELECT p FROM Pedido p WHERE p.estado = :estado AND p.total > :minimo")
List<Pedido> buscar(@Param("estado") EstadoPedido estado, @Param("minimo") BigDecimal minimo);

// ⚠️ CASO ESPECIAL: el ORDEN y los nombres de columna NO se pueden parametrizar.
// ❌
var sqlOrden = "SELECT * FROM pedidos ORDER BY " + campo + " " + direccion;
// ✅ lista blanca estricta
private static final Set<String> ORDENABLES = Set.of("fecha", "total", "estado");
if (!ORDENABLES.contains(campo)) throw new IllegalArgumentException("campo no permitido");
Sort orden = Sort.by(Sort.Direction.fromString(direccion), campo);   // fromString ya valida ASC/DESC

// ─── 3) Inyección de comandos del sistema ───────────────────────────────────────
// ❌ VULNERABLE: el shell interpreta ; | && $() como separadores/sustituciones
Runtime.getRuntime().exec("convert " + nombreRecibido + " salida.png");
new ProcessBuilder("sh", "-c", "gzip " + rutaRecibida).start();

// ✅ CORRECTO: sin shell, argumentos como lista, rutas validadas
Path base = Path.of("/var/subidas").toAbsolutePath().normalize();
Path entrada = base.resolve(nombreRecibido).normalize();
if (!entrada.startsWith(base)) throw new SecurityException("ruta fuera del directorio permitido");

var pb = new ProcessBuilder("/usr/bin/convert", entrada.toString(), "/var/salida/out.png");
pb.redirectErrorStream(true);
Process p = pb.start();
if (!p.waitFor(10, TimeUnit.SECONDS)) p.destroyForcibly();      // timeout: también es seguridad

// ─── 4) LDAP ────────────────────────────────────────────────────────────────────
// ❌ VULNERABLE: con caracteres especiales en el usuario, el filtro se convierte en otro filtro
String filtro = "(uid=" + usuario + ")";
// ✅ CORRECTO: parámetros con {0}, que Spring escapa según RFC 4515
ldapTemplate.search("", "(uid={0})", new Object[]{usuario}, mapper);

// ─── 5) SpEL: inyección que da EJECUCIÓN DE CÓDIGO ──────────────────────────────
// ❌ CRÍTICO: evaluar una expresión que viene del usuario = RCE
var parser = new SpelExpressionParser();
Object r = parser.parseExpression(expresionDelUsuario).getValue(new StandardEvaluationContext(obj));

// ✅ Si de verdad necesitas expresiones dinámicas, contexto restringido y sin acceso a tipos
EvaluationContext contexto = SimpleEvaluationContext.forReadOnlyDataBinding().build();
Object valor = parser.parseExpression(expresion).getValue(contexto, obj);
// ✅ Mejor todavía: no evalúes expresiones del usuario. Ofrece un enum de operaciones soportadas.

// ─── 6) Plantillas (SSTI) ───────────────────────────────────────────────────────
// ❌ CRÍTICO: el NOMBRE de la vista o el contenido de la plantilla viene del usuario
return "redirect:" + destinoDelUsuario;                 // + open redirect
return new ModelAndView(nombreDeVistaDelUsuario);       // SSTI → RCE en Thymeleaf/FreeMarker
// ✅ Lista blanca de vistas y de destinos.

// ─── 7) Log injection / CRLF ────────────────────────────────────────────────────
// ❌ El usuario mete saltos de línea y falsifica una línea de log completa
log.info("Intento de login de " + emailRecibido);
// ✅ Logging estructurado (JSON: los saltos de línea van escapados en el valor del campo)
//    y saneado explícito si el destino es texto plano
log.info("login_intento email={}", emailRecibido.replaceAll("[\\r\\n]", "_"));

Qué aporta Spring: JdbcTemplate/JdbcClient y Spring Data parametrizan por defecto; Bean Validation (@Valid, @Pattern, @Size) valida en la frontera; LdapTemplate escapa filtros; Thymeleaf escapa la salida.

A04 · Diseño inseguro

Qué es: fallos que no se arreglan con código porque el diseño era incorrecto: no se pensó en el abuso. No hay una función mal escrita; falta un control que nadie especificó.

// ─── Caso 1: falta rate limiting → fuerza bruta, enumeración y abuso de coste ───
// ❌ Un endpoint de login (o de "recuperar contraseña", o de OTP, o de búsqueda costosa)
//    sin límite permite millones de intentos por hora. El código es "correcto"; el diseño no.

// ✅ Rate limiting con Bucket4j (por IP y por cuenta, porque solo por IP se sortea con proxies)
@Component
public class FiltroRateLimit extends OncePerRequestFilter {

    private final Cache<String, Bucket> cubos = Caffeine.newBuilder()
            .expireAfterAccess(Duration.ofMinutes(10)).maximumSize(100_000).build();

    private static Bucket nuevoCubo() {
        return Bucket.builder()
                .addLimit(limite -> limite.capacity(10).refillIntervally(10, Duration.ofMinutes(1)))
                .build();
    }

    @Override
    protected void doFilterInternal(HttpServletRequest req, HttpServletResponse res,
                                    FilterChain chain) throws IOException, ServletException {
        String clave = clavePorIpYUsuario(req);
        Bucket cubo = cubos.get(clave, k -> nuevoCubo());
        ConsumptionProbe sonda = cubo.tryConsumeAndReturnRemaining(1);

        if (!sonda.isConsumed()) {
            res.setStatus(HttpStatus.TOO_MANY_REQUESTS.value());          // 429
            res.setHeader("Retry-After",
                    String.valueOf(Duration.ofNanos(sonda.getNanosToWaitForRefill()).toSeconds()));
            log.warn("rate_limit_superado clave={} ruta={}", clave, req.getRequestURI());
            return;
        }
        res.setHeader("X-RateLimit-Remaining", String.valueOf(sonda.getRemainingTokens()));
        chain.doFilter(req, res);
    }

    @Override protected boolean shouldNotFilter(HttpServletRequest req) {
        return !req.getRequestURI().startsWith("/api/auth");        // aplícalo donde importa
    }
}
// Además: bloqueo temporal de cuenta con retroceso exponencial, captcha tras N fallos,
// y el límite duro en el ingress/WAF (un filtro Java no te protege de un DDoS volumétrico).

// ─── Caso 2: lógica de negocio explotable ───────────────────────────────────────
// ❌ Cupón de descuento sin límite de usos: el mismo código aplicado 50 veces → total negativo.
// ❌ Devolución que reembolsa el precio ACTUAL en lugar del pagado → comprar en oferta, devolver caro.
// ❌ "Envío gratis a partir de 50 €": pedir 60 €, devolver una línea y quedarse el envío gratis.
// ✅ Invariantes en el dominio: importe nunca negativo, un cupón por pedido, reembolso ≤ pagado,
//    y recálculo del envío en cada modificación. Y tests de esos casos de abuso.

// ─── Caso 3: race condition en pagos (doble gasto) ──────────────────────────────
// ❌ VULNERABLE: leer-comprobar-escribir sin atomicidad.
//    Dos peticiones simultáneas leen saldo=100, ambas ven que 100 >= 80 y ambas cobran.
@Transactional
public void pagar(Long cuentaId, BigDecimal importe) {
    Cuenta c = repositorio.findById(cuentaId).orElseThrow();
    if (c.getSaldo().compareTo(importe) < 0) throw new SaldoInsuficiente();
    c.setSaldo(c.getSaldo().subtract(importe));       // se pierde una de las dos restas
}

// ✅ CORRECTO: tres capas de defensa
// (a) La condición, en la propia sentencia atómica de la base de datos
@Modifying
@Query("UPDATE Cuenta c SET c.saldo = c.saldo - :importe " +
       "WHERE c.id = :id AND c.saldo >= :importe")
int debitarSiHaySaldo(@Param("id") Long id, @Param("importe") BigDecimal importe);
// filas afectadas = 0 → no había saldo. Atómico, sin condición de carrera.

// (b) Restricción en el esquema: la última línea de defensa es la base de datos
//     ALTER TABLE cuenta ADD CONSTRAINT saldo_no_negativo CHECK (saldo >= 0);

// (c) Idempotencia para evitar el doble cobro por reintentos de red
//     Cabecera Idempotency-Key + índice UNIQUE en (cuenta_id, idempotency_key)
//     El segundo intento choca con la restricción y devuelve el resultado del primero.
// Alternativas: @Version (bloqueo optimista) o SELECT … FOR UPDATE (pesimista). Ver módulo 06.

Mitigaciones estructurales: modelado de amenazas en la fase de diseño (sección 1.3); historias de usuario “negativas” (“como atacante, quiero…”); límites y cuotas por defecto; invariantes en el dominio y restricciones en el esquema; y tests de casos de abuso, no solo de camino feliz.

A05 · Configuración de seguridad incorrecta

# ✅ Configuración correcta de Actuator en producción
management:
  server:
    port: 9090                    # puerto separado: NO se publica en el ingress
  endpoints:
    web:
      exposure:
        include: health,info,prometheus     # lista blanca explícita
        exclude: "*"
      base-path: /interno
  endpoint:
    health:
      show-details: when-authorized
      probes:
        enabled: true             # /health/liveness y /health/readiness para Kubernetes
    env:
      show-values: never          # aunque esté activo, no muestra los valores
    configprops:
      show-values: never
  info:
    env:
      enabled: false              # no expongas propiedades arbitrarias en /info

spring:
  jpa:
    show-sql: false               # las consultas con parámetros acaban en los logs
  h2:
    console:
      enabled: false              # NUNCA en producción: es una consola SQL abierta
server:
  error:
    include-stacktrace: never
    include-message: never
    whitelabel:
      enabled: false

// Test que evita el despiste más caro: publicar con un perfil de desarrollo
@SpringBootTest
class ConfiguracionProduccionTest {

    @Autowired Environment entorno;
    @Autowired WebEndpointProperties actuator;

    @Test
    void no_hay_perfiles_de_desarrollo_activos() {
        assertThat(entorno.getActiveProfiles())
                .doesNotContain("dev", "local", "test-datos");
    }

    @Test
    void actuator_no_expone_endpoints_sensibles() {
        assertThat(actuator.getExposure().getInclude())
                .doesNotContain("*", "env", "heapdump", "configprops", "beans");
    }

    @Test
    void no_hay_secretos_con_valor_por_defecto() {
        assertThat(entorno.getProperty("spring.datasource.password"))
                .isNotIn("", "postgres", "password", "changeme", "admin");
    }
}

A06 · Componentes vulnerables y desactualizados

Una aplicación Spring Boot típica arrastra entre 150 y 400 dependencias transitivas. Tú escribes el 2% del código que ejecutas. Esta categoría no se arregla programando mejor: se arregla con proceso y automatización.

# 1) Saber qué tienes de verdad (incluidas las transitivas)
mvn dependency:tree -Dverbose
mvn dependency:tree -Dincludes=org.apache.logging.log4j     # ¿tengo log4j? ¿en qué versión y por quién?
./gradlew dependencies --configuration runtimeClasspath

# 2) Análisis de composición (SCA) en CI: falla el build si hay CVEs graves
mvn org.owasp:dependency-check-maven:check -DfailBuildOnCVSS=7
trivy fs --scanners vuln,secret,misconfig --severity HIGH,CRITICAL --exit-code 1 .
trivy image --severity HIGH,CRITICAL --exit-code 1 miempresa/pedidos:1.4.2
grype dir:. --fail-on high

# 3) SBOM (inventario firmado de lo que compone el artefacto)
mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom     # → target/bom.json (CycloneDX)
syft packages miempresa/pedidos:1.4.2 -o cyclonedx-json > sbom.json
# Con el SBOM guardado por versión, la pregunta "¿estamos afectados?" se responde con un grep.

# 4) Actualizar con criterio, no a ciegas
mvn versions:display-dependency-updates
mvn versions:display-plugin-updates
# Y sobre todo: el BOM de Spring Boot decide las versiones coherentes. Sube el PADRE,
# no dependencias sueltas, o acabarás con combinaciones que nadie ha probado.

# .github/dependabot.yml — actualizaciones automáticas agrupadas y revisables
version: 2
updates:
  - package-ecosystem: maven
    directory: "/"
    schedule: { interval: weekly }
    open-pull-requests-limit: 10
    groups:
      spring:
        patterns: ["org.springframework*", "org.springframework.boot*"]
      test:
        patterns: ["*junit*", "*mockito*", "*testcontainers*"]
    labels: ["dependencias", "seguridad"]
  - package-ecosystem: docker
    directory: "/"
    schedule: { interval: weekly }
  - package-ecosystem: github-actions      # las propias acciones de CI también tienen CVEs
    directory: "/"
    schedule: { interval: monthly }

A07 · Fallos de identificación y autenticación

// ❌ VULNERABLE — cuatro fallos en catorce líneas
@PostMapping("/login")
public TokenDto login(@RequestBody LoginDto dto) {
    Usuario u = repositorio.porEmail(dto.email())
            .orElseThrow(() -> new NotFound("No existe ningún usuario con ese correo"));  // (1)
    if (!u.getPassword().equals(sha256(dto.password()))) {                                // (2) (3)
        throw new Unauthorized("Contraseña incorrecta");                                  // (1)
    }
    return new TokenDto(emitirToken(u, Duration.ofDays(30)));                             // (4)
}
// (1) ENUMERACIÓN DE USUARIOS: dos mensajes distintos revelan qué correos están registrados.
// (2) SHA-256 rápido y sin salt (sección 2.2).
// (3) Comparación con equals: canal lateral de tiempo. Y sin límite de intentos: fuerza bruta libre.
// (4) Token de 30 días para un cliente público: ventana de exposición enorme.

// ✅ CORREGIDO
@PostMapping("/login")
public ResponseEntity<TokenDto> login(@Valid @RequestBody LoginDto dto, HttpServletRequest req) {
    limitador.comprobar(dto.email(), req.getRemoteAddr());       // 429 con retroceso exponencial

    var usuario = repositorio.porEmail(dto.email());
    // Hash de compensación: si el usuario no existe, gastamos el mismo tiempo → no hay canal lateral
    String hashAComparar = usuario.map(Usuario::getPasswordHash).orElse(HASH_SEÑUELO);
    boolean valido = encoder.matches(dto.password(), hashAComparar) && usuario.isPresent();

    if (!valido) {
        limitador.registrarFallo(dto.email(), req.getRemoteAddr());
        auditoria.loginFallido(dto.email(), req.getRemoteAddr());
        // MENSAJE IDÉNTICO en ambos casos, y sin pistas en el cuerpo ni en el código de estado
        throw new BadCredentialsException("Credenciales no válidas");
    }
    Usuario u = usuario.get();
    if (u.estaBloqueado()) throw new BadCredentialsException("Credenciales no válidas");

    limitador.limpiar(dto.email());
    auditoria.loginCorrecto(u.getId(), req.getRemoteAddr());
    return ResponseEntity.ok(emisor.emitir(u));                  // access 10 min + refresh rotativo
}

Otros puntos de esta categoría que se olvidan:

• Enumeración en registro y en “he olvidado mi contraseña”. El mensaje debe ser siempre “si el correo existe, recibirás un enlace”. Y el correo de recuperación debe llegar igual de rápido en ambos casos (envíalo de forma asíncrona).
• Política de contraseñas moderna (NIST SP 800-63B): longitud mínima 8 (recomendado 12+), máxima al menos 64, permite todos los caracteres y espacios, comprueba contra listas de contraseñas filtradas (es lo que de verdad reduce el riesgo) y no obligues a rotaciones periódicas ni a reglas de composición absurdas: producen Verano2026! y notas adhesivas en el monitor.
• Tokens de recuperación: de un solo uso, con caducidad de 15–30 minutos, generados con SecureRandom, guardados hasheados, invalidados al usarse y al cambiar la contraseña. Y al cambiar la contraseña, invalida todas las sesiones.
• Regeneración del identificador de sesión al autenticarse (sección 3.9) y cierre de sesión que invalide de verdad en el servidor.
• MFA obligatorio para roles administrativos, sin excepciones.

A08 · Fallos de integridad de software y datos

// ─── Deserialización insegura: el caso más grave del ecosistema Java ───────────
// ❌ CRÍTICO: deserializar datos que vienen de fuera con la serialización nativa.
//    Al leer el objeto se ejecutan métodos (readObject, readResolve…) de las clases que haya
//    EN TU CLASSPATH. Encadenando esos métodos (gadget chains) se consigue ejecución de código.
//    No hace falta que TU código haga nada raro: basta con tener ciertas librerías.
ObjectInputStream ois = new ObjectInputStream(peticion.getInputStream());
Object objeto = ois.readObject();                                    // RCE potencial

// ❌ CRÍTICO: tipado polimórfico abierto en Jackson.
//    enableDefaultTyping() (obsoleto) y activateDefaultTyping con un validador permisivo
//    permiten que el JSON diga QUÉ CLASE instanciar → el atacante elige un gadget del classpath.
ObjectMapper mapper = new ObjectMapper();
mapper.enableDefaultTyping();                                        // nunca
mapper.activateDefaultTyping(LaissezFaireSubTypeValidator.instance,  // nunca con datos externos
        ObjectMapper.DefaultTyping.NON_FINAL);

// ✅ CORRECTO (1): no uses serialización nativa con datos externos. JSON con tipos explícitos.
record CrearPedidoDto(@NotBlank String referencia,
                      @NotEmpty List<LineaDto> lineas) { }           // el tipo lo decides TÚ
CrearPedidoDto dto = mapper.readValue(cuerpo, CrearPedidoDto.class);

// ✅ CORRECTO (2): si necesitas polimorfismo, ciérralo con una lista blanca
@JsonTypeInfo(use = JsonTypeInfo.Id.NAME, property = "tipo")
@JsonSubTypes({ @JsonSubTypes.Type(value = Tarjeta.class, name = "tarjeta"),
                @JsonSubTypes.Type(value = Transferencia.class, name = "transferencia") })
public sealed interface MetodoPago permits Tarjeta, Transferencia { }
// o, a nivel de ObjectMapper:
var validador = BasicPolymorphicTypeValidator.builder()
        .allowIfBaseType(MetodoPago.class)
        .allowIfSubType("com.miempresa.pagos.")
        .build();

// ✅ CORRECTO (3): si estás OBLIGADO a la serialización nativa (RMI, JMX, sistemas antiguos),
//    filtro de deserialización (JEP 290, Java 9+) con lista blanca
ObjectInputFilter filtro = ObjectInputFilter.Config.createFilter(
        "com.miempresa.dominio.*;java.util.*;java.lang.*;!*");   // "!*" prohíbe todo lo demás
ois.setObjectInputFilter(filtro);
// A nivel de JVM, para todo el proceso:
//   -Djdk.serialFilter=com.miempresa.**;java.base/**;!*
//   -Djdk.serialFilterFactory=…   (filtros por contexto, Java 17+)
// Y limita la profundidad y el número de referencias: maxdepth=20;maxrefs=1000;maxbytes=100000

La otra mitad de A08 es la cadena de suministro y las actualizaciones: aceptar un artefacto, un plugin, una imagen de contenedor o una actualización automática sin verificar su origen ni su integridad. Se desarrolla en la sección 7.

A09 · Fallos de logging y monitorización

No es una vulnerabilidad que un atacante explote directamente: es lo que hace que no te enteres. Y el tiempo medio de detección de una brecha se sigue midiendo en meses. Un ataque detectado en minutos es un incidente; el mismo ataque detectado en seis meses es una catástrofe regulatoria.

// Evento de auditoría estructurado y separado del log de aplicación
@Component
public class Auditoria {

    private static final Logger AUDIT = LoggerFactory.getLogger("AUDITORIA");

    public void registrar(String accion, String recurso, String resultado) {
        Authentication auth = SecurityContextHolder.getContext().getAuthentication();
        // Campos estables y consultables; nada de frases libres
        AUDIT.info("evento=auditoria actor={} actor_tipo={} accion={} recurso={} resultado={} ip={} trace={}",
                auth != null ? auth.getName() : "anonimo",
                esServicio(auth) ? "servicio" : "usuario",
                accion, recurso, resultado,
                MDC.get("clientIp"), MDC.get("traceId"));
    }
}

// Escuchar los eventos que Spring Security ya publica: auditoría sin tocar tu código
@Component
public class EscuchaSeguridad {

    @EventListener
    void onExito(AuthenticationSuccessEvent e) {
        log.info("evento=login resultado=ok usuario={}", e.getAuthentication().getName());
    }

    @EventListener
    void onFallo(AbstractAuthenticationFailureEvent e) {
        log.warn("evento=login resultado=fallo usuario={} causa={}",
                e.getAuthentication().getName(), e.getException().getClass().getSimpleName());
    }

    @EventListener
    void onDenegado(AuthorizationDeniedEvent<?> e) {
        log.warn("evento=autorizacion resultado=denegado usuario={}",
                e.getAuthentication().get().getName());
    }
}

// Enmascarado: filtro de Logback para que un descuido no acabe en el SIEM
// (además de la disciplina de no loguear lo que no toca)
public class EnmascararSensibles extends MessageConverter {
    private static final Pattern PATRONES = Pattern.compile(
            "(?i)(password|passwd|secret|token|authorization|api[_-]?key)\"?\\s*[:=]\\s*\"?([^\",;\\s]+)");
    @Override public String convert(ILoggingEvent evento) {
        return PATRONES.matcher(super.convert(evento)).replaceAll("$1=***");
    }
}

Alertas que deberías tener configuradas (en Prometheus/Grafana, CloudWatch o el SIEM): picos de 401/403 desde una misma IP o contra un mismo usuario; un usuario que accede a muchos recursos distintos en poco tiempo (patrón de IDOR o de exfiltración); logins correctos desde países o dispositivos nuevos; creación de usuarios administradores; uso de endpoints de administración fuera de horario; caída del volumen de logs (¿alguien ha desactivado el logging?); y despliegues sin pull request asociado.

A10 · SSRF (Server-Side Request Forgery)

Qué es: tu servidor hace una petición HTTP a una URL que controla (total o parcialmente) el usuario. El atacante no llega a esa red, pero tu servidor sí: le sirves de proxy hacia la red interna. Es especialmente devastador en la nube, donde el servicio de metadatos (169.254.169.254) puede entregar credenciales de IAM del rol de la instancia.

// ❌ VULNERABLE — "importar una imagen desde una URL": el clásico
@PostMapping("/productos/{id}/imagen")
public void importar(@PathVariable Long id, @RequestParam String urlImagen) throws IOException {
    try (InputStream in = new URL(urlImagen).openStream()) {          // ← cualquier URL, cualquier red
        almacen.guardar(id, in.readAllBytes());
    }
}
// Lo que un atacante puede pedir (a modo ilustrativo, sin detallar explotación):
//   · el servicio de metadatos de la nube (169.254.169.254) → credenciales temporales de IAM
//   · servicios "internos" que confían en localhost (por ejemplo, Actuator en otro puerto)
//   · la API del clúster de Kubernetes
//   · un escaneo de puertos internos: el TIEMPO de respuesta y el error revelan qué hay abierto
//   · otros esquemas de URL (file:, gopher:, jar:) que amplían el impacto

// ✅ CORREGIDO — lista blanca, resolución explícita y sin redirecciones
@Service
public class DescargadorSeguro {

    private static final Set<String> HOSTS_PERMITIDOS =
            Set.of("cdn.proveedor.com", "imagenes.socio.es");
    private static final long TAMANO_MAXIMO = 5L * 1024 * 1024;

    private final HttpClient cliente = HttpClient.newBuilder()
            .followRedirects(HttpClient.Redirect.NEVER)      // ⚠️ una redirección sortea la lista blanca
            .connectTimeout(Duration.ofSeconds(3))
            .build();

    public byte[] descargar(String urlTexto) throws IOException, InterruptedException {
        URI uri = URI.create(urlTexto);

        // 1) Esquema: solo https
        if (!"https".equalsIgnoreCase(uri.getScheme()))
            throw new IllegalArgumentException("Solo se admite https");

        // 2) Host: lista blanca EXACTA (no "contains", no "endsWith": cdn.proveedor.com.atacante.io)
        String host = uri.getHost();
        if (host == null || !HOSTS_PERMITIDOS.contains(host.toLowerCase(Locale.ROOT)))
            throw new IllegalArgumentException("Host no permitido");

        // 3) Resolver el DNS y comprobar que NINGUNA IP es interna
        //    (protege contra un dominio permitido que resuelva a una dirección privada)
        for (InetAddress ip : InetAddress.getAllByName(host)) {
            if (esInterna(ip)) throw new IllegalArgumentException("Destino interno no permitido");
        }

        // 4) Petición con timeout y límite de tamaño
        HttpRequest peticion = HttpRequest.newBuilder(uri)
                .timeout(Duration.ofSeconds(10))
                .GET().build();
        HttpResponse<byte[]> respuesta = cliente.send(peticion, BodyHandlers.ofByteArray());

        if (respuesta.statusCode() != 200) throw new IOException("Respuesta " + respuesta.statusCode());
        if (respuesta.body().length > TAMANO_MAXIMO) throw new IOException("Fichero demasiado grande");
        if (!esImagenPorFirma(respuesta.body())) throw new IOException("No es una imagen válida");
        return respuesta.body();
    }

    private static boolean esInterna(InetAddress ip) {
        return ip.isLoopbackAddress()      // 127.0.0.0/8, ::1
            || ip.isLinkLocalAddress()     // 169.254.0.0/16  ← metadatos de la nube
            || ip.isSiteLocalAddress()     // 10/8, 172.16/12, 192.168/16
            || ip.isAnyLocalAddress()
            || ip.isMulticastAddress()
            || esCgnat(ip);                // 100.64.0.0/10
    }
}

6.11 Otras vulnerabilidades que debes conocer

XSS en plantillas y en APIs

<!-- Thymeleaf ESCAPA por defecto: es su mayor virtud de seguridad -->
<p th:text="${comentario}"></p>
<!-- Si el comentario contiene una etiqueta <script>, se renderiza como TEXTO. Correcto. -->

<!-- ❌ th:utext NO escapa: "u" de unescaped. Solo con HTML ya saneado
     (OWASP Java HTML Sanitizer) -->
<div th:utext="${descripcionHtml}"></div>

<!-- ❌ Contextos donde el escapado HTML NO BASTA porque el contexto no es HTML -->
<script>var usuario = "[[${nombre}]]";</script>      contexto JS: usa th:inline="javascript"
<a th:href="${urlDelUsuario}">enlace</a>             un esquema javascript: ejecuta código
<div th:attr="onclick=${accion}">                     manejador de eventos: nunca datos del usuario
<style th:text="${cssDelUsuario}">                    contexto CSS

✅ Reglas: escapa SEGÚN EL CONTEXTO, valida las URLs (solo http/https o rutas relativas),
   nunca inyectes en manejadores de eventos ni dentro de <script> sin th:inline, y añade
   una CSP estricta con nonce como red de seguridad.

En una API REST no hay XSS… salvo que lo provoques tú. Devolver JSON con Content-Type: application/json es seguro (el navegador no lo ejecuta). Se rompe si: sirves contenido subido por el usuario con un Content-Type adivinado (de ahí X-Content-Type-Options: nosniff); devuelves HTML construido a mano; usas JSONP; o el frontend hace innerHTML = respuesta.campo, que es XSS en el cliente y ninguna cabecera del servidor lo evita.

// XXE: endurecer un parser XML (haz un @Bean con esto y no crees factorías a mano)
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);  // lo esencial
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
dbf.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "");
dbf.setAttribute(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "");
dbf.setXIncludeAware(false);
dbf.setExpandEntityReferences(false);

// Mass assignment: el DTO es la mitigación, no un capricho de arquitectura
// ❌
@PutMapping("/usuarios/{id}")
public Usuario actualizar(@PathVariable Long id, @RequestBody Usuario usuario) { … }
//   Un PUT con {"nombre":"Ana","rol":"ADMIN","saldo":999999,"emailVerificado":true}
//   escribiría TODOS esos campos.

// ✅
public record ActualizarUsuarioDto(@NotBlank @Size(max = 100) String nombre,
                                   @Email String email) { }        // SOLO lo que puede cambiar

@PutMapping("/usuarios/{id}")
public UsuarioDto actualizar(@PathVariable Long id,
                             @Valid @RequestBody ActualizarUsuarioDto dto,
                             @AuthenticationPrincipal Jwt jwt) {
    return servicio.actualizarPerfil(id, dto, jwt.getSubject());     // y comprueba la propiedad
}

// Subida de ficheros: validar por contenido, no por lo que diga el cliente
private static final Map<String, byte[]> FIRMAS = Map.of(
        "image/png",  new byte[]{(byte) 0x89, 'P', 'N', 'G'},
        "image/jpeg", new byte[]{(byte) 0xFF, (byte) 0xD8, (byte) 0xFF});

public String guardar(MultipartFile fichero) throws IOException {
    if (fichero.getSize() > 5 * 1024 * 1024) throw new PayloadTooLarge();
    byte[] cabecera = Arrays.copyOf(fichero.getBytes(), 8);
    String tipoReal = FIRMAS.entrySet().stream()
            .filter(e -> empiezaPor(cabecera, e.getValue()))
            .map(Map.Entry::getKey).findFirst()
            .orElseThrow(() -> new TipoNoPermitido("Solo PNG o JPEG"));

    String nombre = UUID.randomUUID() + extensionDe(tipoReal);       // el nombre del usuario NO se usa
    almacen.subir(nombre, fichero.getInputStream(), tipoReal);        // bucket privado
    return nombre;
}

7. Cadena de suministro y seguridad del repositorio

7.1 Dependencias: proceso, no heroísmo

Ya vimos las herramientas en A06. Aquí lo importante es el proceso, porque la seguridad de dependencias falla por falta de rutina, no por falta de herramientas.

7.2 SBOM, firma de artefactos y procedencia

# SBOM: la "lista de ingredientes" del artefacto, generada en el build y ARCHIVADA por versión
mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom     # → target/bom.json y bom.xml
syft packages miempresa/pedidos:1.4.2 -o cyclonedx-json > sbom-1.4.2.json

# Con el SBOM archivado, responder a "¿nos afecta el CVE de X?" tarda segundos:
grep -c '"name":"log4j-core"' sbom-1.4.2.json
trivy sbom sbom-1.4.2.json --severity HIGH,CRITICAL   # reevaluar SIN reconstruir la imagen

# Firma sin claves (identidad OIDC de tu CI: no hay secreto que rotar ni que filtrar)
cosign sign --yes ghcr.io/miempresa/pedidos:1.4.2
cosign attest --yes --predicate sbom-1.4.2.json \
              --type cyclonedx ghcr.io/miempresa/pedidos:1.4.2

# Verificación EN EL CLÚSTER antes de admitir la imagen (Kyverno, Gatekeeper, política del runtime)
cosign verify ghcr.io/miempresa/pedidos:1.4.2 \
  --certificate-identity-regexp 'https://github\.com/miempresa/.+' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

# SLSA: niveles de garantía sobre CÓMO se construyó el artefacto
#  L1: existe procedencia documentada
#  L2: build en un servicio alojado, con procedencia firmada
#  L3: build aislado y procedencia no falsificable
# Objetivo realista para un equipo de producto: L2 pronto, L3 en lo que se publica hacia fuera.

7.3 Secretos: el fallo más común y más fácil de evitar

# Detección ANTES de que el secreto entre en el historial (hook local)
gitleaks protect --staged --redact --verbose

# Y en CI, sobre TODO el historial (por si ya entró hace meses):
gitleaks detect --source . --log-opts="--all" --redact

# Con pre-commit, para que lo tenga todo el equipo sin esfuerzo:
#   .pre-commit-config.yaml
#   repos:
#     - repo: https://github.com/gitleaks/gitleaks
#       rev: v8.21.0
#       hooks: [ { id: gitleaks } ]

# Complementos útiles: trufflehog (comprueba si la credencial está VIVA), el escaneo de
# secretos y la "push protection" de GitHub, y detect-secrets con una línea base.

# Spring Boot leyendo secretos de Vault (spring-cloud-starter-vault-config)
spring:
  config:
    import: "vault://secret/pedidos"
  cloud:
    vault:
      uri: https://vault.miempresa.com
      authentication: KUBERNETES     # el pod se autentica con su ServiceAccount: sin secreto inicial
      kubernetes:
        role: pedidos
        service-account-token-file: /var/run/secrets/kubernetes.io/serviceaccount/token
      kv:
        enabled: true
        backend: secret
  datasource:
    # El valor lo resuelve Vault en el arranque; el YAML del repositorio no contiene el secreto.
    # Y SIN valor por defecto: si Vault no responde, la aplicación NO ARRANCA (fallar de forma segura).
    password: ${db-password}

7.4 Endurecer el repositorio y la integración continua

# .github/workflows/ci.yml — permisos mínimos y controles de seguridad en el pipeline
name: CI
on:
  pull_request:
  push: { branches: [main] }

permissions:
  contents: read                 # ← por defecto MÍNIMO; se amplía solo en el job que lo necesita

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  verificar:
    runs-on: ubuntu-latest
    steps:
      # Acciones ancladas por SHA, no por tag: un tag se puede mover a código malicioso
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683   # v4.2.2
        with: { fetch-depth: 0 }

      - uses: actions/setup-java@8df1039502a15bceb9433410b1a100fbe190c53b # v4.5.0
        with: { java-version: '21', distribution: temurin, cache: maven }

      - name: Fugas de secretos
        run: gitleaks detect --source . --redact

      - name: Compilar y probar
        run: mvn -B verify

      - name: SAST
        run: mvn -B com.github.spotbugs:spotbugs-maven-plugin:check   # con find-sec-bugs

      - name: SCA de dependencias
        run: mvn -B org.owasp:dependency-check-maven:check -DfailBuildOnCVSS=7

      - name: SBOM
        run: mvn -B org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom

      - name: Escaneo de la imagen
        run: trivy image --severity HIGH,CRITICAL --exit-code 1 miempresa/pedidos:${{ github.sha }}

      - uses: actions/upload-artifact@v4
        with: { name: sbom, path: target/bom.json }

  publicar:
    needs: verificar
    if: github.ref == 'refs/heads/main'
    permissions:
      contents: read
      packages: write
      id-token: write            # necesario para firmar con cosign sin claves (OIDC)
    environment: produccion      # con revisores obligatorios configurados en el entorno
    runs-on: ubuntu-latest
    steps: []                    # build, push y cosign sign

8. Seguridad en la nube y en contenedores

Resumen con enfoque de seguridad; el detalle de Docker, Kubernetes, despliegue y observabilidad está en módulo 09.

# Dockerfile endurecido para una aplicación Spring Boot 3
# ─── Fase de construcción ─────────────────────────────────────────────────────
FROM maven:3.9-eclipse-temurin-21 AS build
WORKDIR /app
COPY pom.xml .
RUN mvn -B dependency:go-offline
COPY src ./src
RUN mvn -B clean package -DskipTests && \
    java -Djarmode=tools -jar target/app.jar extract --layers --destination /app/extraido

# ─── Fase de ejecución ────────────────────────────────────────────────────────
FROM gcr.io/distroless/java21-debian12:nonroot     # sin shell, sin gestor de paquetes, sin curl
WORKDIR /app
COPY --from=build --chown=nonroot:nonroot /app/extraido/dependencies/ ./
COPY --from=build --chown=nonroot:nonroot /app/extraido/application/  ./
USER nonroot                                       # UID 65532: NUNCA root
EXPOSE 8080
ENTRYPOINT ["java","-XX:MaxRAMPercentage=75","org.springframework.boot.loader.launch.JarLauncher"]

POR QUÉ CADA DECISIÓN:
 · imagen distroless o mínima → decenas de CVEs menos y superficie de ataque ínfima
 · sin shell                  → un RCE no encuentra /bin/sh con el que moverse
 · usuario no root            → un escape del proceso no es root en el nodo
 · multi-stage                → el JDK, Maven, el código fuente y ~/.m2 NO viajan a producción
 · capas de Spring Boot       → mejor caché y despliegues más rápidos (menos ventana de parcheo)

# Kubernetes: contexto de seguridad restrictivo (Pod Security Standard "restricted")
apiVersion: apps/v1
kind: Deployment
metadata: { name: pedidos }
spec:
  template:
    spec:
      serviceAccountName: pedidos          # SA propia con RBAC mínimo (NUNCA la "default")
      automountServiceAccountToken: false  # si el pod no habla con la API de K8s, no le des token
      securityContext:
        runAsNonRoot: true
        runAsUser: 65532
        fsGroup: 65532
        seccompProfile: { type: RuntimeDefault }
      containers:
        - name: app
          image: ghcr.io/miempresa/pedidos@sha256:3f1c9a…   # por DIGEST: inmutable y verificable
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true                    # nada de escribir en la imagen
            capabilities: { drop: ["ALL"] }                 # ninguna capacidad de Linux
          resources:                                       # los límites TAMBIÉN son seguridad
            requests: { cpu: 250m, memory: 512Mi }
            limits:   { cpu: "1",  memory: 1Gi }
          volumeMounts:
            - { name: tmp, mountPath: /tmp }                # el único directorio escribible
      volumes:
        - name: tmp
          emptyDir: { medium: Memory, sizeLimit: 64Mi }
---
# Política de red: denegar el egreso y permitir solo lo necesario.
# Es LA mitigación arquitectónica del SSRF y del movimiento lateral.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: pedidos-egreso }
spec:
  podSelector: { matchLabels: { app: pedidos } }
  policyTypes: [Egress]
  egress:
    - to: [{ podSelector: { matchLabels: { app: postgres } } }]
      ports: [{ port: 5432 }]
    - to: [{ namespaceSelector: { matchLabels: { name: kube-system } } }]     # DNS
      ports: [{ port: 53, protocol: UDP }]
    - to: [{ ipBlock: { cidr: 0.0.0.0/0,
                        except: ["169.254.169.254/32", "10.0.0.0/8"] } }]     # sin metadatos
      ports: [{ port: 443 }]

9. Privacidad y cumplimiento

9.1 RGPD: lo que un desarrollador necesita saber de verdad

El Reglamento General de Protección de Datos (RGPD, o GDPR) no es solo un asunto del departamento legal: varios de sus principios se traducen directamente en decisiones de código y de esquema. En España lo complementa la LOPDGDD y la autoridad de control es la AEPD.

9.2 Datos personales en logs y en entornos de prueba

// Generar datos de prueba realistas SIN datos reales (Datafaker + Testcontainers, módulo 07)
var faker = new Faker(new Locale("es", "ES"));
for (int i = 0; i < 1_000; i++) {
    repositorio.save(new Cliente(
            faker.name().fullName(),
            faker.internet().emailAddress(),
            faker.address().streetAddress(),
            faker.number().numberBetween(18, 90)));
}

// Enmascarado en la capa de presentación (no en la de dominio: allí necesitas el valor)
public static String enmascararIban(String iban) {
    if (iban == null || iban.length() < 8) return "••••";
    return iban.substring(0, 4) + "•".repeat(iban.length() - 8) + iban.substring(iban.length() - 4);
}

// Serialización: que un DTO no arrastre por accidente un campo sensible
public record ClienteDto(
        Long id,
        String nombre,
        @JsonProperty(access = JsonProperty.Access.WRITE_ONLY) String password,  // entra, nunca sale
        @JsonIgnore String iban,
        String ibanEnmascarado) { }

// Y en la entidad, un toString() que no filtre nada en un log
@Override
public String toString() {
    return "Cliente[id=" + id + "]";          // ni nombre, ni email, ni dirección
}

9.3 PCI-DSS, tokenización y auditoría de acceso

Si tu aplicación toca datos de tarjetas, entras en el alcance de PCI-DSS. La estrategia correcta no es “cumplir PCI-DSS”, sino salir del alcance:

• No almacenes nunca el PAN completo. Guarda un token del proveedor de pagos, la marca y los cuatro últimos dígitos. Con eso puedes mostrar el método de pago, cobrar recurrentemente y hacer devoluciones.
• Nunca, bajo ninguna circunstancia, almacenes el CVV (ni cifrado ni “solo un rato”). Está prohibido explícitamente tras la autorización.
• Que el número no pase por tus servidores. Usa campos alojados por el PSP (iframes o elementos tipo Stripe Elements / Redsys): el dato viaja del navegador al proveedor y tú recibes un token. Esto reduce drásticamente tu cuestionario de cumplimiento (SAQ A en lugar de SAQ D).
• Nunca en logs. Ni el PAN, ni el CVV, ni la respuesta completa del PSP. Enmascara en el interceptor del cliente HTTP.
• Segmentación y auditoría: si algún componente sí maneja datos de tarjeta, aíslalo en su propia red, con acceso mínimo, cifrado a nivel de campo, registro de cada acceso y revisión periódica.

-- Auditoría de acceso a datos personales: obligatoria de facto para el RGPD
-- y la única forma de detectar el abuso por parte de usuarios internos.
CREATE TABLE auditoria_acceso_datos (
    id           BIGSERIAL PRIMARY KEY,
    momento      TIMESTAMPTZ  NOT NULL DEFAULT now(),
    actor        VARCHAR(100) NOT NULL,      -- quién (usuario o servicio)
    actor_tipo   VARCHAR(20)  NOT NULL,      -- 'usuario' | 'servicio'
    accion       VARCHAR(40)  NOT NULL,      -- 'LEER' | 'EXPORTAR' | 'MODIFICAR' | 'BORRAR'
    entidad      VARCHAR(60)  NOT NULL,      -- 'Cliente'
    entidad_id   VARCHAR(60)  NOT NULL,      -- el id, NO el contenido del dato
    motivo       VARCHAR(200),               -- nº de ticket de soporte, por ejemplo
    ip           INET,
    trace_id     VARCHAR(40)
);

-- Índices para las consultas que de verdad harás en una investigación
CREATE INDEX idx_aud_actor_momento  ON auditoria_acceso_datos (actor, momento DESC);
CREATE INDEX idx_aud_entidad        ON auditoria_acceso_datos (entidad, entidad_id, momento DESC);

-- Reglas de oro de una tabla de auditoría:
--   · SOLO INSERT: el usuario de la aplicación no tiene UPDATE ni DELETE sobre ella
--     REVOKE UPDATE, DELETE ON auditoria_acceso_datos FROM app_pedidos;
--   · Retención definida y particionado por mes para poder archivar y purgar.
--   · Nunca guardes el VALOR del dato consultado: guardas quién vio qué registro, no su contenido.
--   · Copia hacia un destino externo e inmutable (WORM), fuera del alcance de la aplicación.

-- Consulta típica de detección: ¿alguien está mirando demasiados clientes?
SELECT actor, count(DISTINCT entidad_id) AS clientes_distintos
FROM   auditoria_acceso_datos
WHERE  entidad = 'Cliente' AND accion = 'LEER' AND momento > now() - interval '1 hour'
GROUP  BY actor
HAVING count(DISTINCT entidad_id) > 50;      -- umbral según tu operación normal

10. Proceso: SDLC seguro, incidentes y vulnerabilidades

10.1 Ciclo de vida seguro

SDLC SEGURO — qué se hace en cada fase y con qué coste de corregir

 REQUISITOS         DISEÑO            DESARROLLO         PRUEBAS          PRODUCCIÓN
     │                 │                   │                 │                 │
 · requisitos      · modelado de      · linters +       · DAST en        · WAF y rate limiting
   de seguridad      amenazas           SAST en el IDE    staging        · monitorización y alertas
   explícitos        (STRIDE)         · revisión de     · pruebas de     · gestión de parches
 · clasificación   · elección de        código con        autorización   · respuesta a incidentes
   de datos          controles          checklist         por rol        · pentest periódico
 · normativa       · decisiones       · SCA en cada     · escaneo de     · bug bounty
   aplicable         registradas        PR                imagen         · postmortems
     │                 │                   │                 │                 │
 COSTE RELATIVO DE ARREGLAR EL MISMO FALLO:
     1x               ~5x                ~10x             ~30x           ~100x  (+ multa
                                                                                  + reputación)

 Eso es todo el argumento del "shift-left": no es una moda, es aritmética.

10.2 Respuesta a incidentes

CICLO DE RESPUESTA A INCIDENTES (NIST SP 800-61)

 PREPARACIÓN ──► DETECCIÓN ──► CONTENCIÓN ──► ERRADICACIÓN ──► RECUPERACIÓN ──► LECCIONES
  (antes)          y ANÁLISIS                                                   APRENDIDAS
                                                                                    │
      └─────────────────────── realimenta la preparación ◄────────────────────────┘

 PREPARACIÓN (lo único que se hace con calma, así que hazlo bien)
   · Runbook escrito y accesible SIN acceso a los sistemas comprometidos.
   · Roles: quién decide, quién comunica, quién investiga, quién habla con negocio y con legal.
   · Canal de comunicación alternativo (si el atacante está dentro, no uses el chat corporativo).
   · Contactos: proveedor de nube, seguro, asesoría jurídica, autoridad de control.
   · Logs centralizados, con retención suficiente y FUERA del alcance del atacante.
   · Simulacros: una vez al año como mínimo. Un runbook nunca ensayado no funciona.

 DETECCIÓN Y ANÁLISIS
   · ¿Qué sistemas? ¿Qué datos? ¿Desde cuándo? ¿Sigue el acceso activo?
   · Preserva evidencias ANTES de tocar nada: snapshot del disco y de la memoria, copia de logs.
   · Cronología escrita desde el primer minuto: hora, quién, qué observó, qué hizo.

 CONTENCIÓN  (rápido, pero pensando)
   · Aislar (política de red, grupo de seguridad), NO apagar sin más: apagar destruye
     la memoria y con ella la evidencia. Y a veces avisa al atacante.
   · Rotar credenciales y revocar sesiones y tokens (aquí se paga el precio del JWT no revocable).
   · Bloquear el vector: parchear, cerrar el endpoint, activar una regla de WAF.

 ERRADICACIÓN
   · Eliminar persistencia: cuentas creadas, claves SSH, webshells, tareas programadas,
     imágenes o funciones modificadas, reglas de reenvío de correo.
   · Reconstruir desde una imagen limpia y verificada. NO "limpiar" un servidor comprometido.

 RECUPERACIÓN
   · Restaurar servicio de forma controlada, con monitorización reforzada.
   · Verificar integridad de datos y de copias de seguridad ANTES de restaurarlas.

 LECCIONES APRENDIDAS  (en 1–2 semanas, por escrito)
   · SIN CULPABLES: se busca la causa sistémica, no la persona. Si hay culpa, no habrá informes
     sinceros la próxima vez, y eso es peor que el incidente.
   · Acciones concretas con dueño y fecha. Y al menos un TEST AUTOMÁTICO nuevo.

 RELOJ REGULATORIO: 72 h para notificar a la autoridad de control desde que se CONOCE la
 brecha de datos personales. Es un plazo corto: la decisión de notificar se toma con
 información incompleta y debe estar prevista en el runbook, no improvisada.

10.3 Gestión de vulnerabilidades y formación

Formación del equipo: lo que funciona no es el curso anual de dos horas que todos hacen con el vídeo en otra pestaña. Funciona lo que está pegado al trabajo diario: un campeón de seguridad por equipo (una persona con interés y tiempo asignado, no un cargo honorífico); revisar los hallazgos reales del propio proyecto en la reunión semanal; laboratorios prácticos (PortSwigger Academy, Juice Shop, WebGoat) en horario laboral; sesiones de modelado de amenazas donde se aprende haciendo; y difundir los postmortems sin culpables, que son el material didáctico más eficaz que existe porque hablan de vuestro propio sistema.

11. Errores comunes y soluciones

12. Preguntas frecuentes

13. Ejercicios y retos

14. Resumen y recursos