El problema con los allowlists
Los allowlists de SQL se diseñaron para un mundo donde las consultas las escribían personas y rara vez cambiaban. Ese mundo ya no existe.
- Mantenimiento manual — Cada consulta nueva debe agregarse manualmente a la lista. Si olvidas una, queda bloqueada en producción.
- Frágiles — Cambios menores como espacios en blanco, alias de columnas o reordenar parámetros rompen las coincidencias por completo.
- Binarios — Sin niveles de severidad, sin marcado, sin modo de monitoreo. Es permitir o denegar, nada intermedio.
- Sin contexto — No pueden distinguir
DELETE FROM users WHERE id = 5deDELETE FROM users. Ambas son solo texto. - Fáciles de eludir — El emparejamiento de texto se sortea fácilmente con comentarios, trucos de codificación o reestructuración de la consulta.
En qué se diferencia Vericto
Vericto no empareja texto. Entiende la estructura.
- Análisis completo de AST — Entiende la estructura de la consulta, no solo el texto. Los espacios en blanco, los comentarios y el formato son irrelevantes.
- Automático — Funciona con cualquier consulta sin registro previo. Sin lista que mantener, sin consultas que aprobar.
- Granular — 5 niveles de severidad (crítico, alto, medio, bajo, informativo) combinados con 3 acciones de aplicación (bloquear, marcar, monitorear).
- Determinista — La misma entrada siempre produce el mismo resultado. Sin varianza estadística, sin deriva de modelo.
- Cero mantenimiento — Las reglas se aplican estructuralmente, no por consulta. Una sola regla cubre infinitas variaciones de consulta.
Comparación lado a lado
| Característica | Allowlists de SQL | Vericto |
|---|---|---|
| Gestión de consultas nuevas | Deben agregarse manualmente | Se evalúan automáticamente |
| Método de detección | Emparejamiento de texto/regex | Análisis completo de AST |
| Falsos positivos | Altos (espacios en blanco, alias) | Cero (análisis estructural) |
| Niveles de severidad | Ninguno (solo permitir/denegar) | 5 niveles (de crítico a informativo) |
| Acciones de aplicación | Solo bloquear | Bloquear / Marcar / Monitorear |
| Esfuerzo de mantenimiento | Alto (por consulta) | Cero (las reglas son estructurales) |
| Sobrecarga de latencia | Variable (complejidad del regex) | P99 < 2ms (nativo compilado) |
| Detección de inyección de SQL | Limitada | Detección completa de tautologías |
| Consulta segura sugerida | No | Sí (generada automáticamente) |
| Registro de auditoría | Normalmente ninguno | Registro completo e inmutable |
| Integración con CI/CD | Scripts manuales | API HTTP nativa |
Migración desde los allowlists
Cambia de los allowlists a Vericto sin interrumpir tu tráfico de producción.
No se requieren cambios de código. Vericto funciona como un proxy transparente: tu aplicación se conecta a Vericto en lugar de conectarse directamente a la base de datos. Cero modificaciones a nivel de aplicación.
- Despliega el proxy — Apunta tu cadena de conexión al proxy de Vericto. Toma menos de 5 minutos.
- Activa el modo de observación — Vericto evalúa todas las consultas pero no bloquea nada. Ves qué se marcaría.
- Valida — Revisa el registro de auditoría, ajusta los umbrales de severidad y confirma que no se bloquearían consultas legítimas.
- Aplica — Cambia al modo de aplicación. Las consultas destructivas ahora se bloquean en tiempo real.
El despliegue gradual es totalmente compatible. Puedes aplicar la protección en tablas específicas, niveles de severidad específicos o tipos de consulta específicos mientras mantienes el resto en modo de observación.
Deja de mantener allowlists manualmente
Deja que el análisis estructural se encargue de la seguridad de las consultas. Despliega en menos de 5 minutos.