Qué es el diseño inseguro: diseño frente a implementación

En el curso Seguridad web con OWASP Top 10 vio un resumen de las diez categorías. Ahora se detendrá en una que no se parece a las demás: A04:2021, diseño inseguro. La mayoría de las fallas del Top 10 viven en una línea de código concreta. Esta vive antes del código, en las decisiones que el equipo tomó, o dejó de tomar, cuando pensó la aplicación.

Qué es el diseño inseguro

En una frase: el diseño inseguro es la ausencia o debilidad de controles de seguridad en la forma en que se pensó una aplicación, es decir, en sus reglas, sus flujos y sus suposiciones.

Separe dos momentos del desarrollo. El diseño es decidir qué hará el sistema: quién puede hacer cada cosa, en qué orden, cuántas veces y con qué límites. La implementación es escribir el código que cumple esas decisiones. Un error puede nacer en cualquiera de los dos.

Dos tipos de error muy distintos

Imagine dos problemas en la puerta de una bodega:

• El cerrajero instaló bien la cerradura, pero dejó el tornillo flojo. Es un error de implementación: el plan era correcto y la ejecución falló.
• La bodega nunca tuvo cerradura, porque nadie pensó que alguien quisiera entrar. Es un error de diseño: aunque el cerrajero sea perfecto, no hay nada que instalar.

En software, una consulta SQL armada concatenando texto es un error de implementación. Una tienda que permite aplicar el mismo cupón cien veces porque nadie definió un límite por cliente tiene un error de diseño: el código hace exactamente lo que se pidió; lo que se pidió estaba mal. OWASP lo resume así: un diseño inseguro no se arregla con una implementación perfecta, porque los controles necesarios nunca se definieron.

Cómo se ve en la práctica

Esta función de una app de pagos ficticia usa consultas parametrizadas y valida tipos, y aun así es insegura:

@app.post("/api/transferir")
def transferir():
    datos = request.get_json()
    monto = int(datos["monto"])
    comision = int(datos["comision"])  # la calcula el navegador
    db.execute(
        "UPDATE cuentas SET saldo = saldo - ? WHERE id = ?",
        (monto + comision, session["cuenta_id"]),
    )
    return {"ok": True}

No hay inyección ni error de sintaxis. El problema es una decisión: el servidor confía en la comisión que envía el cliente, no limita montos ni verifica saldo. Ninguna herramienta de análisis estático lo marcará como inyección; hace falta pensar en el negocio. La ficha de Flask llega en el módulo 2.

Breve historia y contexto

Durante casi veinte años el Top 10 habló sobre todo de errores de implementación. En 2021 OWASP reconoció que eso no basta: la seguridad debe empezar antes del código.

Por qué ocurre

1. Requisitos sin seguridad: la historia de usuario dice "el cliente puede transferir dinero" y nada sobre límites, horarios o verificación.
2. Presión por entregar: se diseña el camino feliz y se deja "la seguridad para después".
3. Suposiciones no escritas: "nadie va a llamar la API directamente".
4. Falta de conocimiento del negocio: el equipo técnico no sabe qué es un fraude típico en pagos.
5. Ausencia de revisión de diseño: nadie de seguridad mira el flujo antes de programarlo.

Por qué importa en ciberseguridad y en el trabajo

Las fallas de diseño se explotan con peticiones válidas, así que escáneres, analizadores de código y firewalls casi nunca las ven. Y son caras de corregir tarde: en la pizarra cuestan una conversación; en producción, rehacer un flujo.

El tema aparece en el trabajo diario de quien desarrolla, quien diseña la arquitectura, el equipo de seguridad de aplicaciones, quien hace pruebas autorizadas y el analista de SOC o de fraude que detecta el abuso. Quien no lo domina aprueba sistemas que pierden dinero sin que nada "falle" técnicamente.

Dónde se encuentra

Conceptos clave