Guía de seguridad
Lista de seguridad Web3: 15 pasos para proteger tu smart contract
Una lista completa y accionable, del control de acceso al monitoreo — para detectar vulnerabilidades antes que los atacantes.
Lista de seguridad previa al despliegue
Completa estas 15 comprobaciones antes de desplegar cualquier smart contract a mainnet.
Implementa control de acceso por roles
Usa AccessControl u Ownable2Step de OpenZeppelin en lugar de comprobaciones crudas de dirección. Define roles separados para admin, operador y pauser. Nunca uses tx.origin para autorizar.
Protégete contra reentrancy
Aplica el patrón checks-effects-interactions a todas las llamadas externas. Usa ReentrancyGuard en funciones que transfieran ETH o interactúen con contratos no confiables. Prueba con contratos de callback deliberadamente maliciosos.
Valida todas las entradas externas
Comprueba direcciones cero, valores de overflow, arrays vacíos y parámetros fuera de rango en la entrada de las funciones. Nunca asumas que el caller enviará datos sensatos — aplica las restricciones on-chain.
Maneja la aritmética de enteros con seguridad
Solidity 0.8+ incluye chequeos de overflow, pero los bloques unchecked los omiten. Audita cada bloque unchecked por riesgo de overflow/underflow. Vigila la división por cero y la pérdida de precisión en matemáticas de punto fijo.
Asegura las dependencias de oráculos
Usa precios promedio ponderados en el tiempo (TWAP) o varias fuentes de oráculo para resistir manipulación con flash loans. Añade chequeos de frescura, umbrales mínimos de respuesta y lógica de fallback si el oráculo falla.
Fija y verifica la versión del compilador
Fija Solidity con un pragma concreto (p. ej. 0.8.20) en lugar de pragmas flotantes (^0.8.0). Todos los contratos del proyecto deben compilar con la misma versión para evitar diferencias sutiles de comportamiento.
Minimiza la superficie de upgrade
Si usas proxies actualizables, restringe la autoridad de upgrade con timelocks y gobernanza multisig. Evita colisiones de layout de storage. Pregúntate si de verdad hace falta upgradeability — un contrato inmutable es más fácil de razonar.
Implementa mecanismos de parada de emergencia
Añade pausabilidad en operaciones críticas. Diseña la pausa para que no se abuse como censura, pero sí detenga operaciones durante un exploit activo. Prueba que la pausa bloquea de verdad todas las rutas críticas.
Protégete contra front-running
Usa esquemas commit-reveal, mempools privadas (Flashbots Protect) o deadlines en operaciones sensibles al tiempo. Minimiza el valor extraíble en transacciones pendientes.
Audita los patrones de approval de tokens
Evita approvals infinitos cuando puedas. Implementa EIP-2612 permit para approvals sin gas. Revisa condiciones de carrera en approvals y usa decreaseAllowance en lugar de approve(0) seguido de approve(newAmount).
Prueba con simulaciones realistas en forks
Ejecuta tests de integración contra forks de mainnet para pillar problemas con balances reales, estados de pool y valores de oráculo. Hardhat y Foundry soportan testing en fork — úsalo para simular el despliegue real.
Revisa el trade-off gas vs. seguridad
El código hiperoptimizado en gas puede introducir fallos sutiles. Nunca omitas chequeos de seguridad para ahorrar gas. Documenta cada bloque unchecked o uso de assembly con una justificación explícita de seguridad.
Verifica el source en el explorador
Publica y verifica el código en Etherscan o el explorador correspondiente justo después del despliegue. Eso permite escrutinio público y genera confianza. El source verificado debe coincidir exactamente con el bytecode desplegado.
Configura monitoreo y alertas
Despliega monitoreo on-chain antes del lanzamiento, no después. Vigila patrones de transferencia inusuales, escalada de privilegios, propuestas de gobernanza y cambios de parámetros. Herramientas como la capa de monitoreo 24/7 de FinGuard detectan exploits activos en tiempo real.
Contrata una auditoría de seguridad independiente
La revisión interna es necesaria pero no suficiente. Contrata un auditor independiente que intente explotar tu contrato en un entorno sandbox. Exige evidencia de exploit en los hallazgos, no solo listas teóricas de riesgo.
Vulnerabilidades comunes a vigilar
Estas clases de vulnerabilidad explican la mayoría de los exploits DeFi en 2024-2025.
Ataques de reentrancy
La vulnerabilidad más clásica de smart contracts. El atacante reentra en una función antes de que termine la primera llamada y drena fondos con llamadas recursivas. El hack de The DAO en 2016 perdió 60 M USD con este patrón.
Manipulación de oráculos
Los atacantes usan flash loans para distorsionar temporalmente los feeds de precio on-chain y explotar protocolos que dependen del spot. Es el vector líder en DeFi desde 2020.
Fallos de control de acceso
Chequeos de permiso ausentes o incorrectos en funciones privilegiadas — cualquiera puede llamar operaciones de admin, cambiar parámetros o drenar fondos. Suele deberse a cobertura incompleta de modifiers.
Exploits con flash loans
Pedir prestadas cantidades grandes de forma atómica para manipular votos de gobernanza, ratios de pool o mecanismos de precio en una sola transacción. La defensa exige valores ponderados en el tiempo y confirmación en varios bloques.
Bugs de lógica en reglas de negocio
Implementación incorrecta de tipos de lending, cálculo de recompensas o umbrales de liquidación. Estos bugs son específicos de cada protocolo: por eso las herramientas automáticas no bastan — el razonamiento humano pilla fallos de diseño.
Requisitos de testing
El estándar mínimo de pruebas antes de que un smart contract vaya a mainnet.
Tests unitarios (cobertura 90 %+)
Cada función public y external debe tener casos positivos y negativos. Apunta al menos al 90 % de cobertura de ramas. Mide con forge coverage de Foundry o los plugins de coverage de Hardhat.
Tests de integración en forks de mainnet
Prueba el flujo completo de despliegue sobre un estado forkeado de mainnet. Verifica que las interacciones con pools DEX, protocolos de lending y oráculos se comporten como se espera con datos on-chain reales.
Fuzz testing con invariantes de propiedad
Define invariantes (p. ej. el supply total nunca supera el tope, el balance del usuario nunca es negativo) y deja que un fuzzer genere miles de entradas aleatorias. Foundry y Echidna son las herramientas líderes.
Verificación formal de rutas críticas
En contratos de alto valor que gestionan TVL significativo, usa herramientas de verificación formal (Certora, Solidity SMTChecker) para demostrar matemáticamente que las propiedades críticas se cumplen con cualquier entrada.
Preguntas frecuentes
¿Cuánto tarda completar esta lista?
En un proyecto bien estructurado con cobertura de tests existente, reserva 2–5 días para los 15 puntos. Si partes de cero, 1–2 semanas para control de acceso, infraestructura de tests y monitoreo.
¿Pueden las herramientas automáticas sustituir una revisión manual?
Las herramientas automáticas (analizadores estáticos, fuzzers, verificación formal) pillan patrones conocidos con eficiencia, pero se pierden fallos de lógica de negocio, diseño económico y vectores nuevos. Lo mejor es combinar automatización para amplitud y revisión experta para profundidad — exactamente cómo funciona el pipeline de 7 capas de FinGuard.
¿Cuál es el punto más importante de esta lista?
Si solo puedes hacer una cosa, contrata una auditoría independiente (#15). Un auditor experimentado cubrirá la mayoría del resto en su revisión. Pero apoyarte solo en la auditoría sin implementar los demás puntos genera trabajo y riesgo innecesarios.
¿Hago esta lista antes o después de la auditoría?
Antes. Completarla hace que el auditor busque issues profundos y no evidentes en lugar de marcar higiene básica. Obtienes más valor por cada dólar gastado. Es como limpiar la casa antes de que llegue el inspector.
¿Listo para una auditoría profesional?
Completa tu lista y deja que el motor de IA de 7 capas de FinGuard verifique el trabajo con exploits reales en sandbox.