¿Qué es una inyección SQL y cómo la prevenís en tu código? ¿Alcanza con escapar las comillas del input?

Qué es: la inyección SQL ocurre cuando un dato del usuario se concatena dentro del texto de una consulta. Así el motor lo interpreta como parte del SQL y no como un valor. Un atacante podría leer o modificar datos que no le corresponden.

Defensa principal: consultas parametrizadas (prepared statements). La consulta y los datos viajan por separado, y el motor nunca ejecuta el valor como código.

# Vulnerable
cursor.execute(f"SELECT * FROM users WHERE email = '{email}'")

# Seguro
cursor.execute("SELECT * FROM users WHERE email = %s", (email,))

¿Alcanza con escapar comillas? No. Escapar a mano es frágil: depende del motor, del charset y del contexto. Además no protege valores numéricos sin comillas, como

WHERE id = 1 OR 1=1

.

Otras capas:

• Usar un ORM o query builder sin armar SQL crudo con strings. Si hace falta SQL crudo, que también vaya parametrizado.
• Validar contra una allowlist las partes que no se pueden parametrizar, como nombres de columnas en un ORDER BY o la dirección ASC/DESC.
• Aplicar mínimo privilegio: el usuario de la base que usa la app no debería poder hacer DROP ni leer tablas ajenas.
• No mostrar errores de la base al usuario y registrarlos internamente.

Detección: herramientas SAST en el pipeline que marquen concatenación en queries, code review y alertas en los logs por errores de sintaxis SQL inusuales. Un WAF suma como capa extra, pero no reemplaza la corrección en el código. Para practicar, conviene usar laboratorios propios como DVWA o Juice Shop.

Decir que basta con sanitizar o escapar el input, o que un WAF lo resuelve todo. Olvidar que identificadores como columnas o el ORDER BY no se pueden parametrizar y requieren allowlist.