La inyección SQL es una vulnerabilidad donde un atacante inserta SQL malicioso a través de la entrada del usuario — manipulando consultas de base de datos para robar datos, eludir autenticación o dañar datos. Es una de las vulnerabilidades web más peligrosas y clásicas, pero es prevenible con técnicas adecuadas.
When user input is concatenated directly into a SQL query, an attacker can INJECT SQL:
query = ;
La entrada del atacante se trata como código SQL en lugar de datos — permitiéndole reescribir la consulta (eludir login, descargar todos los datos, eliminar tablas).
// ✅ PARAMETERIZED / PREPARED statements — input is treated as DATA, never as code
const query = 'SELECT * FROM users WHERE email = ?';
db.execute(query, [userInput]); // the value is safely bound, not concatenated
// → the database treats userInput as a literal value → injection impossible
Las consultas parametrizadas (prepared statements) separan el código SQL de los datos — la entrada nunca puede ser interpretada como SQL. Esta es la defensa primaria y confiable.
✓ PARAMETERIZED queries / prepared statements → the #1 fix (always use them)
✓ ORMs/query builders → use parameterization under the hood (but don't bypass with raw
string concatenation)
✓ INPUT VALIDATION (defense in depth) — validate/sanitize, but NOT a substitute for
parameterization
✓ LEAST PRIVILEGE DB accounts (limit damage); avoid exposing detailed DB errors
→ NEVER build queries by concatenating user input.
Entender la inyección SQL y cómo prevenirla es esencial porque es una de las vulnerabilidades web más peligrosas, clásicas y comunes (parte de la categoría de inyección de OWASP), pero totalmente prevenible, por lo que es conocimiento de seguridad imprescindible para cualquier desarrollador que trabaje con bases de datos.
Entender cómo funciona — que concatenar entrada del usuario directamente en consultas SQL permite a un atacante inyectar código SQL (su entrada tratada como código en lugar de datos), permitiéndole eludir autenticación (' OR '1'='1), descargar todos los datos, o incluso eliminar tablas ('; DROP TABLE) — es necesario para reconocer y evitar la vulnerabilidad.
La inyección SQL puede ser catastrófica (filtración completa de datos, destrucción de datos, elusión de autenticación), lo que la hace críticamente importante.
Entender la prevención es esencial: las consultas parametrizadas (prepared statements) son la solución primaria y confiable — separan el código SQL de los datos para que la entrada del usuario se trate como un valor literal que nunca puede ser interpretado como SQL, haciendo imposible la inyección.
Esta es la defensa #1 que todo desarrollador debe usar.
Entender las defensas adicionales — usar ORMs/constructores de consultas (que parametrizan, pero no eludirlos con concatenación cruda), validación de entrada como defensa en profundidad (pero no como sustituto de la parametrización), cuentas de base de datos con privilegios mínimos, y evitar exposición de errores detallados — y la regla cardinal de nunca concatenar entrada del usuario en consultas refleja una prevención integral.
Ya que la inyección SQL es una vulnerabilidad peligrosa, común y clásica con consecuencias graves (filtración de datos, pérdida de datos, elusión de autenticación) que es totalmente prevenible con consultas parametrizadas, y ya que entender cómo funciona y cómo prevenirla es esencial para cualquier desarrollador que trabaje con bases de datos, entender la inyección SQL y su prevención es conocimiento de seguridad esencial, imprescindible — una vulnerabilidad fundamental que entender y defenderse, donde la solución simple y confiable (consultas parametrizadas) es conocimiento crítico que previene una de las clases de ataques más dañinos.