Seguridad web: nunca confíes en la entrada del usuario

Toda vulnerabilidad web que veas a este nivel es una regla rota: nunca confíes en la entrada que viene de fuera de tu programa. Tu navegador, tu formulario, tu API y tu cookie están todos fuera. La entrada no es "mala": es texto perfectamente válido. El fallo es que tu programa dejó de tratarla como datos y permitió que se convirtiera en parte de un comando, una consulta, una página o una petición.

the page builds a greeting from the name you typed

name you typed:   Ada
page shows:       Hello, Ada

name you typed:   <script>...</script>
page shows:       the browser obeys the script instead of printing it

cause: the server put your text into the page without escaping itEl usuario escribió texto. La página decidió que era marcado. El navegador no tenía forma de distinguirlo.

La inyección SQL es el mismo error una capa más abajo. Si el código pega texto del usuario dentro de una cadena SQL, un valor como una dirección de correo deja de ser un valor y pasa a formar parte de la gramática de la consulta. El ejemplo clásico es un formulario de acceso donde el texto que sigue a una comilla convierte el resto de la consulta en un comentario. La defensa no es buscar comillas: es usar parámetros, para que la base de datos reciba siempre la estructura de la consulta y los valores por separado y nunca tenga que adivinar qué es qué.

SELECT id, email FROM users
WHERE email = 'student@example.org' AND password_hash = '...';

-- the same query, built by gluing user input into the text:
--   1 OR 1=1 --
-- the condition stops being a condition and becomes a statementUn valor pegado en el texto de la consulta se convierte en texto de la consulta. Un parámetro sigue siendo un valor, por raro que parezca.