Dónde viven los datos, y quién los pide

Cuando abriste /agenda-interna viste una tabla con cuatro pacientes. Esa tabla no estaba escrita en ningún archivo llamado agenda-interna.

Lo que pasó fue esto: el servidor recibió tu petición, le preguntó a una base de datos por las citas del día, y con lo que le devolvió construyó la página que viste. La página se fabricó en el momento, para ti, y se tiró.

Una base de datos es, en esencia, un conjunto de tablas: filas y columnas, como una hoja de cálculo pero pensada para que muchos programas pregunten a la vez sin pisarse.

Y se le pregunta en un idioma propio, el SQL, que se parece bastante al inglés:

SELECT nombre, hora, servicio FROM citas WHERE fecha = '2026-09-01'

«Dame el nombre, la hora y el servicio de la tabla de citas, donde la fecha sea hoy.» Eso es lo que corrió por debajo mientras tú mirabas una tabla en el navegador.

Aquí es donde vuelve la idea del módulo 2: la confusión entre un dato y una orden.

La mayoría de las consultas no son fijas. Llevan algo que puso el usuario: lo que escribiste en un buscador, el número de tu historia, un filtro. El programa arma la consulta pegando ese trozo dentro.

Si lo pega sin cuidado, quien escribe puede dejar de ser un dato y pasar a ser parte de la orden. En vez de buscar un nombre, cierra la frase y añade la suya. Eso se llama inyección, y lleva veinte años entre los primeros puestos de todas las listas de fallos graves.

No hace falta que sepas escribir una todavía. Lo que sí conviene que se te quede es la forma del problema, porque la vas a reconocer en sitios muy distintos:

Cada vez que un sistema mete texto de un desconocido dentro de algo que luego se ejecuta —una consulta, un comando, una página— hay que asegurarse de que ese texto no pueda cambiar el significado de lo que rodea.

La solución no es «prohibir las comillas». Es no pegar: se manda la orden por un lado y los datos por otro, para que la base de datos sepa cuál es cuál. Eso es lo que verás llamado consultas parametrizadas.

Cierra el círculo con la clínica. Su fallo no fue de base de datos: la consulta estaba bien, la tabla estaba bien. Lo que faltaba era la pregunta de antes: ¿tiene derecho este a ver esto?

Y ahí está la distinción que conviene llevarse de todo el módulo:

• Autenticación es saber quién eres. Iniciar sesión.
• Autorización es saber qué puedes hacer. Que tú, siendo quien eres, puedas o no ver la agenda completa.

La clínica no falló en la primera —ni siquiera había una— sino en la segunda. Y son fallos distintos con arreglos distintos: poner una pantalla de acceso delante no arregla nada si después nadie comprueba qué puede ver cada quien.

Es la razón por la que en la sala de defensa, de las tres medidas, la que arreglaba el problema de verdad era la tercera: revisar quién puede ver cada pantalla. Bloquear una dirección y limitar peticiones daban tiempo. Esa quitaba el fallo.