¿Cómo previenen la inyección SQL las sentencias preparadas?
Respuesta breve
Las sentencias preparadas envían primero la plantilla de la consulta a la base de datos, con marcadores de posición, de modo que la estructura queda fijada antes de que llegue ningún dato del usuario. Los parámetros se vinculan después como datos puros y nunca pueden interpretarse como SQL — así que una entrada como ' OR 1=1 se trata como una cadena literal, no como código. Esta separación es la solución canónica y fiable contra la inyección.
Las sentencias preparadas (consultas parametrizadas) son la defensa canónica contra la inyección SQL porque atacan la causa raíz: la inyección SQL solo existe porque los datos y el código viajan juntos en una sola cadena. Las sentencias preparadas los separan.
Cómo funciona la separación
La consulta se envía a la base de datos en dos fases:
- Preparar. La aplicación envía la plantilla de la consulta con marcadores de posición, por ejemplo
SELECT * FROM users WHERE email = ?. La base de datos analiza, compila y planifica esta sentencia antes de ver ninguna entrada del usuario. La estructura queda ahora bloqueada. - Vincular y ejecutar. Los valores proporcionados por el usuario se envían por separado y se vinculan a los marcadores de posición como datos tipados. Nunca se vuelven a analizar como SQL.
Así, si un atacante envía ' OR 1=1 --, la base de datos trata toda esa cadena como un valor literal para comparar con la columna email. Busca un usuario cuyo correo sea literalmente ' OR 1=1 --, no encuentra ninguno y no devuelve nada. La carga útil nunca se convierte en parte de la lógica de la consulta.
Por qué el escapado es la alternativa más débil
El escapado manual intenta neutralizar los caracteres peligrosos en una cadena concatenada — pero es fácil hacerlo mal (problemas de juego de caracteres, contextos olvidados, campos numéricos sin comillas). Las sentencias preparadas eliminan toda esa clase de error.
Dónde se quedan cortas
Los marcadores de posición solo funcionan para valores de datos, no para identificadores — no puedes parametrizar un nombre de tabla, un nombre de columna o la dirección de un ORDER BY. Si esos deben ser dinámicos, debes usar una lista de permitidos estricta que asocie la entrada del usuario con identificadores conocidos y seguros. Los ORM suelen usar sentencias preparadas internamente, pero las vías de escape en SQL crudo pueden reintroducir la inyección.
Los entrevistadores buscan la explicación «la estructura se compila antes de que lleguen los datos», el ejemplo concreto de ' OR 1=1 convirtiéndose en un literal, y la conciencia de la limitación de identificadores que requiere listas de permitidos.
Posibles preguntas de seguimiento
- ¿Por qué no puedes usar un marcador de posición para un nombre de tabla o columna?
- ¿Cómo se relaciona un ORM con las sentencias preparadas?
- ¿Cuándo sigue siendo necesario el escapado o la lista de permitidos?