Threat modeling de una app chica

Threat modeling suena a reunión de tres horas con consultores. No lo es. En el fondo son cuatro preguntas que te hacés mirando un dibujo de tu app: ¿qué estás construyendo? ¿qué puede salir mal? ¿qué vas a hacer al respecto? ¿lo hiciste bien? El resto es disciplina, no herramientas.

Paso 1: dibujá el flujo de datos

No podés proteger lo que no ves. Un data flow diagram muestra por dónde viajan los datos y, sobre todo, dónde cruzan un trust boundary: el límite entre algo que controlás y algo que no.

flowchart LR
U[Usuario / navegador] -->|HTTPS| A[API / backend]
A -->|query| D[(Base de datos)]
A -->|lee/escribe| S[(Bucket de archivos)]
A -->|llama| X[API externa de pagos]
subgraph confiable [Tu infraestructura]
  A
  D
  S
end

Todo lo que cruza desde “Usuario” hacia “Tu infraestructura” es input no confiable. Esa frontera es donde viven la mayoría de los bugs de seguridad.

Paso 2: STRIDE como checklist

STRIDE es un acrónimo para no olvidarte ninguna familia de amenaza. Recorrés cada flecha del diagrama y te preguntás las seis:

S  Spoofing        ¿alguien puede hacerse pasar por otro?       → autenticación
T  Tampering       ¿pueden alterar datos en tránsito o reposo?  → integridad, TLS, validación
R  Repudiation     ¿pueden negar que lo hicieron?               → logs, auditoría
I  Info disclosure ¿se filtra info que no debería?              → cifrado, mínimo privilegio
D  Denial of svc   ¿pueden tirarlo abajo o saturarlo?           → rate limiting, timeouts
E  Elevation       ¿pueden ganar permisos que no les tocan?     → authz, IDOR

Paso 3: priorizá por impacto, no por miedo

Vas a encontrar más amenazas de las que podés arreglar hoy. Ordenalas por impacto × probabilidad, no por cuál suena más aterradora:

amenaza                          impacto   prob.   prioridad
IDOR en /facturas/{id}           alto      alta    🔴 ahora
Sin rate limit en /login         medio     alta    🟠 pronto
Logs sin el actor de la acción   medio     media   🟡 backlog
DoS por payload gigante          bajo      baja    ⚪ después

Paso 4: cada amenaza, una mitigación

El modelo recién sirve cuando cada riesgo alto tiene una acción concreta y un responsable:

amenaza                  mitigación concreta
IDOR en /facturas/{id}   chequeo de ownership: owner_id == sub (404 si no)
Sin rate limit en login  límite por IP + backoff; alertar sobre picos
Repudiation              log con actor, acción, recurso y timestamp
Info disclosure en S3    Block Public Access + roles de IAM acotados