Probar los contratos inteligentes como si fueras el atacante: OWASP prioriza el control de acceso
Los controles habituales son inútiles donde nadie intenta hacer lo que no se le permitió.
La comprobación más peligrosa de un contrato inteligente comienza al intentar hacer lo que está prohibido al usuario. OWASP situó los errores de control de acceso en primer lugar del Smart Contract Top 10 de 2026. Ese defecto permite que una dirección ajena llame a una función privilegiada, modifique un estado crítico o tome el control del protocolo.
El primer lugar no significa el mayor daño económico. OWASP contabilizó 30 incidentes de este tipo en 2025 por aproximadamente $220 millones. El control de acceso ocupó el segundo puesto tanto por el total de pérdidas como por la frecuencia, pero los participantes de la encuesta valoraron ese riesgo por encima de los demás. El conjunto completo de OWASP abarcó 122 incidentes únicos con contratos inteligentes por alrededor de $905,4 millones.
Publicada el 7 de septiembre, la guía Shattered propone diseñar pruebas desde la perspectiva del atacante. En lugar de comprobar solo el escenario autorizado, el desarrollador introduce direcciones externas y se asegura de que la llamada a una función administrativa termine en rechazo. Luego se prueban direcciones aleatorias mediante fuzzing para buscar restricciones omitidas.
Se comprueba por separado la reinicialización de contratos actualizables, la jerarquía de roles, la posibilidad de escalar privilegios propios y el derecho a cambiar la implementación a través de proxies. OpenZeppelin recomienda proteger especialmente DEFAULT_ADMIN_ROLE, ya que ese rol por defecto gestiona otros roles y de hecho se convierte en la llave del sistema de permisos.
El riesgo ya se ha manifestado en ataques reales. En mayo, la compromisión de Wasabi Protocol mostró cómo el acceso administrativo y la ausencia de demora en el cambio de permisos permitieron extraer más de $5 millones. OWASP, entre los casos importantes de 2025, también clasifica como SC01 los ataques a UPCX, Infini, UXLINK y Cork Protocol.
El problema se vuelve más complejo tras el despliegue del código. En junio, los contratos inteligentes antiguos de Aztec recordaron otra cara del riesgo: un contrato inmutable puede seguir almacenando activos cuando los desarrolladores ya renunciaron a las facultades administrativas y no pueden intervenir rápidamente tras detectar un error.