Estrictamente hablando, en realidad no es necesario escapar, porque el valor del parámetro nunca se interpola en la cadena de consulta.
La forma en que funcionan los parámetros de consulta es que la consulta se envía al servidor de la base de datos cuando llama a prepare() , y los valores de los parámetros se envían más tarde, cuando llamó a execute() . Por lo tanto, se mantienen separados de la forma textual de la consulta. Nunca hay una oportunidad para la inyección SQL (siempre que PDO::ATTR_EMULATE_PREPARES es falso).
Así que sí, los parámetros de consulta lo ayudan a evitar esa forma de vulnerabilidad de seguridad.
¿Son 100% a prueba contra cualquier vulnerabilidad de seguridad? No claro que no. Como sabrá, un parámetro de consulta solo ocupa el lugar de un único valor literal en una expresión SQL. No puede hacer que un solo parámetro sustituya una lista de valores, por ejemplo:
SELECT * FROM blog WHERE userid IN ( ? );
No puede usar un parámetro para hacer que los nombres de las tablas o las columnas sean dinámicos:
SELECT * FROM blog ORDER BY ?;
No puede usar un parámetro para ningún otro tipo de sintaxis SQL:
SELECT EXTRACT( ? FROM datetime_column) AS variable_datetime_element FROM blog;
Entonces, hay bastantes casos en los que debe manipular la consulta como una cadena, antes de prepare() llamar. En estos casos, aún debe escribir el código con cuidado para evitar la inyección de SQL.
