Asegure NL2SQL contra la inyección SQL de LLM

Un mensaje del sistema que dice "solo genera consultas SELECT" es una preferencia, no una barrera. El modelo lo respeta la mayor parte del tiempo porque ha sido entrenado para seguir las instrucciones, no porque una restricción técnica le impida físicamente escribir algo más. Dos clases de fracasos hacen que esta confianza en la producción sea insuficiente.

La primera surge de la propia pregunta. Un usuario, mal intencionado o simplemente creativo en su formulación, puede dirigir la pregunta de tal manera que empuje el modelo hacia SQL que no debería haber escrito: una unión a una tabla sensible, un filtro que elude la lógica esperada, una llamada a una función del sistema. El modelo no distingue entre una pregunta legítima y otra diseñada para manipularla.

El segundo no requiere malicia. Un modelo puede alucinar el nombre de una tabla, olvidar el LIMIT que solicitó el mensaje o generar un SELECT * sin restricciones en una tabla grande. El resultado es el mismo en ambos casos: SQL potencialmente costoso o intrusivo, que ha pasado el filtro de solicitud y está a punto de ejecutarse en una base de datos real.

La primera línea de defensa es analizar el SQL producido por el modelo con un analizador real para el dialecto de destino y luego validar la estructura resultante, no el texto sin formato. La búsqueda de palabras prohibidas en la cadena de caracteres (“DROP”, “DELETE”, “;”) se omite trivialmente: mayúsculas y minúsculas diferentes, comentario insertado en medio de una palabra clave, comillas escritas. Un árbol de sintaxis describe sin ambigüedades lo que realmente hace la consulta.

Aurabase implementa este paso con la caja Rust sqlparser y su dialecto PostgreSqlDialect. Incluso antes del análisis, un primer filtro léxico rechaza dos construcciones que son difíciles de razonar correctamente una vez en el árbol: cotizaciones de dólares ($$...$$), que pueden ocultar contenido arbitrario en una cadena, y comentarios de varias líneas (/* */), que pueden ocultar el final real de una instrucción.

let dialect = PostgreSqlDialect {};
let mut statements = Parser::parse_sql(&dialect, sql)
    .map_err(|e| AuraError::BadRequest(format!("Erreur de parsing SQL: {}", e)))?;

if statements.len() > 1 {
    return Err(AuraError::BadRequest("Multi-statements non autorisés".to_string()));
}

Este rechazo de declaraciones múltiples por sí solo bloquea la forma más conocida de inyección SQL mediante apilamiento: SELECT * FROM users; DROP TABLE users;--. El analizador solo devuelve una instrucción procesable, la segunda simplemente nunca se alcanza, sin importar cómo esté redactada en la pregunta original.

Una vez obtenido el árbol, la validación más amplia es aceptar solo un tipo de nodo raíz, una consulta (Statement::Query), y rechazar todo lo demás: INSERT, UPDATE, DELETE, DROP, CREATE, ALTER. Ya no es una instrucción rápida, es una condición sobre el tipo de objeto analizado, que ninguna formulación hábil de la pregunta puede eludir.

Incluso dentro de un SELECT, varias construcciones siguen siendo peligrosas y merecen su propio rechazo explícito:

Un caso de prueba tomado del repositorio ilustra concretamente el último punto: SELECT * INTO backup FROM users es rechazado, aunque no contiene ni una palabra clave de escritura visible ni una función sospechosa. La forma de la solicitud es suficiente para descalificarla.

Una lista negra de funciones prohibidas (pg_sleep, pg_read_file, dblink...) requiere anticipar cada función peligrosa una por una, mientras Postgres expone varios cientos de ellas. Una lista blanca invierte la carga de la prueba: solo se autorizan diez funciones, count, sum, avg, min, max, lower, upper, coalesce, date_trunc, now. Todo lo demás está prohibido de forma predeterminada, incluida una característica legítima que nadie ha pensado en agregar todavía.

Un único pase de validación no siempre es suficiente. Un recorrido estructural del árbol enumera sus puntos de entrada uno por uno (proyección, DÓNDE, JOIN, GROUP BY...), y es fácil olvidar uno: una función prohibida se puede ocultar en una cláusula FILTER (WHERE pg_sleep(10) IS NOT NULL), en un ORDER BY intraagregado (sum(id ORDER BY pg_sleep(10))), en WITHIN GROUP, DISTINCT ONo OFFSET.

#[test]
fn test_rejette_fonction_interdite_dans_filter() {
    assert!(validate(
        "SELECT count(*) FILTER (WHERE pg_sleep(10) IS NOT NULL) FROM users",
        None, None
    ).is_err());
}

Por tanto, el validador de Aurabase añade una segunda pasada exhaustiva, que recorre todas las expresiones del árbol donde quiera que estén, independientemente de la ruta estructural. Es una supuesta defensa en profundidad: si el primer pase falla en un caso, el segundo lo alcanza.

SELECT * sigue autorizado, es útil para la minería de datos. El riesgo no es la estrella, es la ausencia de un techo a una consulta escrita por un modelo: una pregunta mal formulada puede traer de vuelta una tabla entera, con el coste de memoria y el tiempo de respuesta que eso implica.

Aurabase aplica una regla sencilla y transparente. Si el SQL generado no tiene un LIMIT, el servidor agrega uno (100 líneas por defecto, valor anunciado al modelo en el indicador del sistema). Si SQL solicita un LIMIT más allá de un límite máximo (1000 filas de forma predeterminada), la consulta se rechaza explícitamente en lugar de reducirse silenciosamente. Ambos valores son configurables en el lado del servidor (AI_NL2SQL_DEFAULT_LIMIT, AI_NL2SQL_MAX_LIMIT) y el servidor incluso se niega a iniciarse si la falla excede el límite máximo.

{
  "sql": "SELECT count(*) FROM orders WHERE status = 'paid' LIMIT 100",
  "limit": 100,
  "limit_injected": true
}

Dos filtraciones distintas amenazan un motor NL2SQL conectado a una base de datos real: el acceso al catálogo del sistema Postgres y el acceso a un esquema que no pertenece a la persona que llama. Ambos se bloquean tras la validación, independientemente de cualquier política RLS colocada en sentido posterior.

pg_catalog siempre es parte de search_path, lo que significa que un nombre no calificado como pg_authid o pg_stat_activity accede a él directamente, sin prefijo. El validador de Aurabase bloquea cualquier nombre que comience con pg_, así como information_schema y el esquema interno aura_console, ya sea calificado o no.

En un nombre de dos componentes (schema.table), solo se permite el esquema del proyecto que realiza la llamada; cualquier otro valor se rechaza. Un nombre con tres o más componentes se rechaza automáticamente. Este límite en el nivel de consulta generada se suma al aislamiento a nivel de base de datos que se detalla en nuestro artículo sobreaislamiento multiinquilino: uno evita que el SQL generado apunte a otro esquema, el otro evita que la conexión misma llegue a otra base de datos. Ninguno reemplaza al otro.

Una trampa discreta acecha a cualquier API NL2SQL que acepte un parámetro que describa el esquema o las tablas permitidas en la consulta del cliente. Si se utiliza este mismo parámetro para construir el mensaje y validar el SQL de salida, una persona que llama puede mentir sobre lo que está permitido y la validación luego valida contra esta mentira en lugar de contra la realidad de la base de datos.

Aurabase realiza una introspección del esquema base del proyecto real en cada llamada, con un breve caché de treinta segundos para el rendimiento, y rechaza explícitamente (error 400) cualquier campo schema, allowed_schemao schema_context enviado en el cuerpo de la solicitud, en lugar de aceptarlo y luego sobrescribirlo silenciosamente. La diferencia importa: un campo aceptado y luego ignorado da la ilusión de un control que no existe; un campo rechazado lo dice de inmediato.

Ya sea que utilice Aurabase o cree su propio proceso sobre un LLM genérico, los siguientes puntos cubren lo que con mayor frecuencia se pasa por alto.

Si escribe el validador usted mismo

• Analice SQL con un analizador real para su dialecto exacto, nunca con coincidencia de patrones en una cadena.
• Adopte un rechazo predeterminado: se debe rechazar cualquier tipo de nodo, cualquier función no autorizada explícitamente, no sólo los casos peligrosos ya identificados.
• Acepte solo una declaración por consulta; este es el rechazo más simple contra consultas acumuladas.
• Pruebe el validador con casos adversarios reales (función prohibida en FILTER, en un ORDER BY intraagregado, en OFFSET), no solo con casos obvios.
• A pesar de todo, ejecute el SQL validado con un rol de Postgres con privilegios reducidos sobre el esquema esperado: el validador limita la forma de la consulta, el rol limita lo que puede lograr físicamente si se le escapa un caso.

Si está evaluando un marco NL2SQL de terceros

• Pregunte explícitamente si la validación es estructural (AST) o sólo una instrucción rápida: la respuesta lo cambia todo.
• Verifique que se aplique un límite de línea de forma predeterminada, no solo documentado como una práctica recomendada a su cargo.
• Compruebe si el cliente API puede proporcionar el esquema utilizado para la validación, lo que reabriría exactamente la falla descrita anteriormente.
• Compare varias herramientas según este criterio específico antes de elegir: nuestra comparación de las herramientas NL2SQL detalla lo que distingue los enfoques disponibles en 2026.

Un validador AST sólido reduce el riesgo en el origen: el SQL que llega a su base de datos ya tiene un formato conocido y acotado. Sin embargo, no reemplaza las políticas RLS en sus tablas confidenciales, que deciden qué filas tiene derecho a ver un usuario determinado. Las dos capas responden a preguntas diferentes: el validador limita la forma de la consulta generada, el RLS limita los datos que puede devolver para un usuario específico. Mantenga ambos activos, incluso si uno parece redundante con el otro.

NL2SQL cubre preguntas estructuradas sobre sus tablas. Para preguntas sobre contenido no estructurado, documentos, notas, tickets, el RAG nativo de Aurabase sigue una lógica de seguridad comparable, detallada en nuestro tutorial de canalización de RAG en pgvector.