¿Qué es una inyección SQL y cómo evitarla al crear una web?
Publicado el 2026-10-20 por frfrand
SQL injection explicada para principiantes: qué ocurre al mezclar consultas y datos, por qué funcionan las consultas parametrizadas y cómo reducir riesgos.
Una inyección SQL es una vulnerabilidad que aparece cuando una aplicación incorpora datos no confiables dentro de instrucciones SQL de forma insegura. En determinadas condiciones, un atacante puede hacer que el motor de base de datos interprete parte de esos datos como código y ejecute una consulta diferente de la prevista.
La idea esencial es muy sencilla: una cosa son los datos que escribe una persona y otra las instrucciones que decide ejecutar el programa. Confundirlos es el problema.
El ejemplo de una hoja de pedidos
Imaginá que atendés una tienda. Tu sistema permite buscar un producto por nombre. Lo correcto sería usar el nombre como dato dentro de una consulta ya definida.
Pero un programa mal diseñado podría fabricar la consulta uniendo fragmentos de texto con lo que haya escrito el usuario. Así, alguien puede intentar introducir caracteres o instrucciones que cambien el significado de la búsqueda.
No necesitamos construir un ataque para entender el error: ocurre porque el programa deja que el contenido externo intervenga en la estructura de una instrucción.
¿Qué podría pasar?
Dependiendo de los permisos de la cuenta utilizada por la aplicación y de cómo se construyan las consultas, el fallo puede permitir obtener información que no corresponde, modificar registros o afectar la disponibilidad del servicio.
Eso no significa que toda inyección SQL otorgue control completo del servidor. El impacto depende de múltiples factores: consultas posibles, motor utilizado, permisos y arquitectura.
Por eso limitar los privilegios del usuario de base de datos es una protección adicional valiosa, aunque no corrija la vulnerabilidad de origen.
¿Cómo se evita? Las consultas parametrizadas
La defensa más importante consiste en separar la estructura SQL de los valores externos. Las consultas parametrizadas utilizan marcadores de posición y pasan los datos aparte, para que el motor los trate como valores y no como fragmentos de código SQL.
En Python con un controlador compatible, un ejemplo conceptual sería:
cursor.execute(
"SELECT id, nombre FROM productos WHERE nombre = %s",
(nombre_buscado,)
)El marcador utilizado depende de la biblioteca. Lo importante no es copiar literalmente ese símbolo en cualquier lenguaje, sino utilizar el mecanismo oficial de parámetros del controlador.
No se recomienda construir la consulta concatenando manualmente comillas alrededor del dato. Escapar caracteres a mano suele ser frágil y muy fácil de hacer mal.
¿Qué pasa con los ORM?
Frameworks como Django incluyen un ORM que permite realizar muchas consultas sin escribir SQL manualmente. Esto suele reducir el riesgo cuando se utilizan correctamente sus operaciones y filtros.
Pero utilizar un ORM no te vuelve inmune. Si ejecutás consultas SQL crudas, construís expresiones dinámicas inseguras o aceptás nombres de columnas y tablas sin control, todavía podés introducir problemas.
Para partes dinámicas que no admiten parametrización directa —como algunos identificadores SQL— se necesitan listas explícitas de valores permitidos y métodos adecuados del proveedor.
¿Sirve validar el formulario?
Validar ayuda a que los datos cumplan las reglas del negocio, pero no reemplaza la parametrización.
Que una persona solo pueda introducir veinte caracteres no demuestra que el valor sea seguro para cualquier contexto. Las protecciones deben aplicarse donde se construye la consulta.
También conviene comprobar permisos del usuario de la base: una aplicación que solo lee un conjunto de tablas no debería recibir privilegios administrativos ilimitados.
¿Y un firewall de aplicaciones?
Un WAF puede bloquear determinados patrones maliciosos, pero no corrige el código vulnerable. Algunas peticiones perjudiciales pueden pasar y otras legítimas podrían bloquearse por error.
La solución robusta empieza dentro de la aplicación, con parámetros, autorización y pruebas.
¿Cómo se prueba defensivamente?
Revisá los puntos que aceptan información externa, utilizá pruebas automatizadas y herramientas de análisis apropiadas dentro de un entorno autorizado. Comprobá las consultas que construye el código y verificá que nunca se interpreten los valores como instrucciones.
En producción, evitá mostrar errores SQL detallados al público porque pueden revelar información interna. Mantené los registros útiles para diagnóstico en un sistema protegido.
¿Dónde entra ArduMaker?
Si alojás una aplicación Django, Node o cualquier backend con PostgreSQL en ArduMaker, las consultas son responsabilidad de tu aplicación. El servidor puede mantener la base de datos en una red privada, pero eso no reemplaza la parametrización ni el control de permisos.
En resumen: la inyección SQL aparece cuando los datos cruzan la frontera y se convierten en órdenes. Mantener esa separación es la defensa principal.
Fuentes: Prevención de SQL Injection en OWASP · Guía de PostgreSQL · Cómo se compromete una base de datos.