FundamentosLección 01

Pensar como defensor

Activos, amenazas y riesgo; la tríada CIA; cómo modelar amenazas con STRIDE y los principios que guían cada decisión de seguridad.

Básico14 min de lectura

Al terminar sabrás

Distinguir activo, amenaza, vulnerabilidad, exploit y riesgo.
Usar la tríada CIA para saber qué propiedad rompe un ataque.
Modelar las amenazas de un endpoint con STRIDE.
Aplicar defensa en profundidad, mínimo privilegio y "fallar cerrado".

Antes de escribir una sola línea de configuración conviene tener un modelo mental. La seguridad no consiste en “poner autenticación”; consiste en proteger cosas valiosas de gente que quiere abusar de ellas, con un coste razonable. Todo lo demás —contraseñas, tokens, filtros— son herramientas al servicio de esa idea.

El vocabulario mínimo

Término	Qué es	Ejemplo en una API de notas
Activo	Algo con valor que hay que proteger	Las notas privadas, las contraseñas, la cuenta de admin
Amenaza	Algo que podría dañar un activo	Que un usuario lea las notas de otro
Vulnerabilidad	Una debilidad que hace posible la amenaza	El endpoint `GET /notes/{id}` no comprueba el dueño
Exploit	La forma concreta de aprovecharla	Cambiar `/notes/41` por `/notes/42` en la URL
Riesgo	Probabilidad × impacto	Alto: es trivial de explotar y expone datos privados
Control	La medida que reduce el riesgo	Filtrar la consulta por `owner = usuario autenticado`
Superficie de ataque	Todo lo que un atacante puede tocar	Endpoints, formularios, cabeceras, ficheros subidos, dependencias

La tríada CIA: qué propiedad rompe cada ataque

Casi cualquier incidente de seguridad rompe una de tres propiedades. Saber cuál te dice qué tipo de control necesitas.

Confidencialidad, integridad y disponibilidad: las tres propiedades que protege la seguridad de la información.

Confidencialidad: solo lee quien debe leer. La rompe una fuga de datos, un token interceptado o un endpoint que devuelve más campos de la cuenta.
Integridad: los datos y las acciones no se alteran sin que se note. La rompe un precio modificado en el carrito, un JWT manipulado o una transferencia que el usuario no pidió (CSRF).
Disponibilidad: el sistema responde cuando se le necesita. La rompe una avalancha de peticiones al login, una consulta que tarda minutos o un fichero gigante subido a propósito.

A menudo se añaden dos más: autenticidad (sabes quién envió algo) y no repudio (quien lo hizo no puede negarlo, gracias a firmas y registros de auditoría).

Modelar amenazas: cuatro preguntas

El modelado de amenazas suena a burocracia, pero en su versión mínima son cuatro preguntas que puedes hacerte frente a una pizarra en 20 minutos:

1¿Qué estamos construyendo?un diagrama con componentes, datos y fronteras de confianza
2¿Qué puede salir mal?STRIDE sobre cada flecha y cada caja
3¿Qué vamos a hacer?mitigar, aceptar, transferir o eliminar
4¿Lo hicimos bien?tests, revisión, pentest

La pieza más útil del primer paso es la frontera de confianza (trust boundary): la línea donde los datos pasan de algo que no controlas (el navegador, la red, otro servicio) a algo que sí. Todo lo que cruza esa línea es sospechoso hasta que lo validas.

STRIDE

STRIDE es una lista de seis categorías de amenazas. Cada letra rompe una propiedad, y cada una tiene un control típico:

Letra	Amenaza	Propiedad que rompe	Ejemplo	Control típico
S	Spoofing (suplantación)	Autenticidad	Iniciar sesión como otro usuario	Autenticación fuerte, MFA
T	Tampering (manipulación)	Integridad	Cambiar el `owner` en el JSON de una petición	Validación, firmas, no confiar en el cliente
R	Repudiation (repudio)	No repudio	“Yo no borré esa nota”	Registro de auditoría
I	Information disclosure (fuga)	Confidencialidad	Un stack trace con rutas y versiones internas	Mínima exposición, cifrado
D	Denial of service	Disponibilidad	Miles de intentos de login por segundo	Rate limiting, límites de tamaño
E	Elevation of privilege	Autorización	Un usuario normal llama a `/admin`	Autorización en el servidor, mínimo privilegio

Los principios que guían cada decisión

Defensa en profundidad

Ningún control es perfecto. Por eso se apilan: si uno falla, el siguiente todavía protege.

Redfirewall, WAF, rate limiting

TransporteTLS / HTTPS

Autenticación¿quién eres?

Autorización¿puedes hacer esto con este recurso?

Validaciónentrada y salida

Datos

Cada capa asume que la anterior puede fallar. Un atacante tiene que atravesarlas todas.

Mínimo privilegio

Cada usuario, servicio y proceso recibe solo los permisos que necesita, y solo durante el tiempo que los necesita. El usuario de base de datos de tu API no necesita DROP TABLE; un token para leer notas no necesita el scope de escritura; un job nocturno no necesita ser administrador.

Seguro por defecto y fallar cerrado

Un sistema bien diseñado empieza cerrado y abres explícitamente lo que hace falta. Y cuando algo falla —una excepción, un servicio caído, un dato inesperado— la respuesta segura es denegar, no permitir.

Evita

boolean canDelete(Long noteId, String user) {
    try {
        return notes.ownerOf(noteId).equals(user);
    } catch (Exception e) {
        return true; // "si falla, que no moleste"
    }
}

Prefiere

boolean canDelete(Long noteId, String user) {
    try {
        return notes.ownerOf(noteId).equals(user);
    } catch (Exception e) {
        log.warn("No se pudo verificar el dueño", e);
        return false; // ante la duda, no
    }
}

Nunca confíes en la entrada

Todo lo que llega del cliente puede estar manipulado: parámetros, cabeceras, cookies, el cuerpo JSON, el nombre de un fichero. El frontend puede ocultar un botón, pero el servidor es el único que decide.

Simplicidad y diseño abierto

Economía del mecanismo: cuanto más simple es un control, más fácil es verificar que funciona. Un filtro JWT casero de 200 líneas tiene más sitios donde equivocarse que una línea de configuración de un componente auditado.
Sin seguridad por oscuridad: el sistema debe ser seguro aunque el atacante conozca su diseño (principio de Kerckhoffs). Lo único secreto deben ser las claves, no el algoritmo ni la URL “difícil de adivinar” del panel de administración.

Mini lab · 15 min

STRIDE sobre un endpoint

Objetivo: Aplicar STRIDE al endpoint DELETE /api/notes/{id} de una API de notas y proponer un control para cada amenaza.

Imagina una API donde cada usuario tiene notas privadas y un administrador puede borrar cualquiera. El endpoint DELETE /api/notes/{id} recibe un token en la cabecera Authorization.

Escribe una amenaza concreta para cada letra de STRIDE.
Para cada una, indica qué propiedad rompe y qué control la mitiga.
Ordena las seis por riesgo (probabilidad × impacto). ¿Cuál atacarías primero si fueras el atacante?

Pista

Piensa en qué pasa si cambias el número de la URL, si el token es de otra persona, si nadie registra quién borró qué, y si alguien llama al endpoint diez mil veces por segundo.

Mostrar respuestaOcultar respuesta

Letra	Amenaza concreta	Propiedad	Control
S	Usar un token robado de otro usuario	Autenticidad	Tokens de vida corta, HTTPS, MFA en el login
T	Enviar `DELETE /api/notes/42` siendo dueño solo de la 41	Integridad	Comprobar el dueño en el servidor (`findByIdAndOwner`)
R	Un admin borra una nota y luego lo niega	No repudio	Registro de auditoría con usuario, IP y hora
I	La respuesta de error revela si la nota 42 existe (“no es tuya” vs “no existe”)	Confidencialidad	Responder 404 en ambos casos
D	Borrado masivo con un script	Disponibilidad	Rate limiting por usuario, borrado lógico
E	Un usuario normal invoca la ruta de borrado de admin	Autorización	Reglas de autorización en el servidor, no solo ocultar el botón

La más probable y grave suele ser la T/E por IDOR (cambiar el id de la URL): es trivial de explotar y la vulnerabilidad número uno en APIs según OWASP. Por eso la lección de autorización le dedica una sección entera.