Esta lección cierra las promesas que el curso lleva haciendo desde el módulo 5. Trata dos cosas que parecen distintas y son la misma: quién decide qué se ejecuta y quién puede ver qué. La primera mitad es la inyección SQL, el fallo de seguridad más viejo y más caro de las aplicaciones con base de datos, explicado desde el lado que importa: cómo se evita. La segunda es el sistema de permisos y roles de PostgreSQL, incluida la seguridad a nivel de fila, con un diseño concreto para TiendaVerde.

Un aviso desde el principio: esto es una lección defensiva. Los ejemplos de ataque que verás son mínimos e inofensivos —una condición que devuelve de más— y están aquí solo para que entiendas por qué falla el enfoque vulnerable. El peso de la lección está en las defensas. Y una advertencia que va en serio: antes de exponer a Internet un sistema con datos reales, encarga una revisión a un profesional de seguridad y consulta el tratamiento de los datos personales con el responsable legal o de protección de datos de tu organización. Lo que sigue es el mínimo que debes saber, no un sustituto de esa revisión.

1. Qué es una inyección SQL
2. Por qué ocurre: datos y código en la misma cadena
3. La defensa: consultas parametrizadas
4. Lo que no es una defensa suficiente
5. El caso especial: identificadores dinámicos
6. Defensa en profundidad
7. Permisos y roles en PostgreSQL
8. Un diseño de roles para TiendaVerde
9. Row Level Security
10. SECURITY DEFINER y el search_path
11. Datos personales
12. Checklist de seguridad
13. Errores Comunes y Consejos
14. Ejercicios
15. Conclusión

El buscador de la tienda recibe un texto y busca productos. Escrito de la peor manera posible —concatenando— queda así:

Con la entrada normal aceite, lo que llega al servidor es SELECT id, nombre, precio FROM productos WHERE activo AND nombre ILIKE '%aceite%';, que es correcto y devuelve lo esperado:

Dos productos. Ahora, la entrada ' OR '1'='1 — un texto perfectamente escribible en cualquier caja de búsqueda. Al concatenarlo, la consulta que se ejecuta es:

Devuelve 19 filas: el catálogo activo entero. La comilla del usuario cerró la cadena que el programador había abierto, y lo que venía detrás dejó de ser texto de búsqueda para convertirse en estructura de la consulta: un OR que nadie escribió. Con la variante ' OR '1'='1' --, el doble guion comenta el resto de la línea, incluido el %' pendiente:

20 filas. Una más: aparecen también las cápsulas de espirulina, el producto descatalogado (activo = FALSE) que la tienda no debería mostrar jamás. Es un ejemplo diminuto y sin daño, y precisamente por eso es útil: el atacante no ha hecho nada raro; ha escrito texto en una caja de texto, y ha conseguido que el filtro de negocio deje de aplicarse. Si en lugar de un catálogo público la consulta hubiera sido la de "mis pedidos" o la de "empleados", el resultado habría sido el mismo mecanismo sobre datos que sí importan.

Y una consecuencia menos obvia pero igual de grave: la entrada O'Connor —un apellido perfectamente normal— rompe la consulta con un error de sintaxis. La misma grieta que permite el ataque hace que el programa falle con datos legítimos. Un código vulnerable a inyección es también un código que no funciona bien.

La causa cabe en una frase, y conviene aprendérsela:

La inyección SQL ocurre porque el código y los datos viajan mezclados en la misma cadena de texto, y el motor no tiene forma de saber qué parte escribiste tú y qué parte escribió el usuario.

El servidor recibe un texto y lo analiza entero. Para él, OR '1'='1' es lenguaje SQL igual que el SELECT que lo precede: no hay ninguna marca que diga "esto venía de un formulario". Todo lo que se deriva de ahí —añadir condiciones, comentar el resto, encadenar sentencias si el conector lo permite— es consecuencia de esa mezcla. De ahí sale la única defensa que funciona de verdad: separar el código de los datos, y que sea el motor quien los junte sabiendo cuál es cuál.

Una consulta parametrizada (o sentencia preparada) manda al servidor dos cosas separadas: el texto con marcadores, y los valores. El servidor analiza y planifica antes de ver los valores; cuando llegan, ya no hay nada que analizar y un valor no puede convertirse en código pase lo que pase. Ni siquiera hace falta escapar comillas: el valor no se inserta en el texto. El mismo buscador, bien escrito, en cuatro entornos:

Con la entrada maliciosa ' OR '1'='1, las cuatro versiones devuelven 0 filas: buscan, literalmente, productos cuyo nombre contenga el texto ' OR '1'='1. Que no exista ninguno es exactamente lo correcto. El ataque deja de ser un ataque y pasa a ser una búsqueda sin resultados.

Y el mecanismo también existe en SQL puro, útil para verlo sin lenguaje de por medio:

Dos matices prácticos. El comodín % va dentro del valor, nunca en el texto SQL: ILIKE '%' || $1 || '%' también funciona, pero entonces conviene escapar los % y _ que traiga el usuario, o una búsqueda de 100% se convertirá en un comodín. Y si vas a filtrar por una lista de valores, no montes la lista concatenando: usa WHERE id = ANY($1) pasando un array, que es lo que soportan todos los conectores modernos.

Nota de dialecto. El marcador cambia según el conector: $1, $2 en PostgreSQL nativo y node-postgres, %s en psycopg, ? en JDBC, PDO y muchos otros, :nombre para parámetros con nombre en PDO, SQLAlchemy o JDBI. Lo que no cambia es la garantía: mientras el valor viaje por el canal de parámetros, no puede convertirse en código. Ojo con PDO: por omisión emula las preparadas escapando en el cliente; desactívalo con ATTR_EMULATE_PREPARES => false para usar las de verdad.

La lista deja una conclusión: no hay grados. O el valor viaja por el canal de parámetros, o no está protegido.

Hay un caso que las consultas parametrizadas no resuelven, y es por donde se cuela la inyección en aplicaciones por lo demás correctas: un parámetro no puede ser el nombre de una tabla, de una columna, ni el sentido de un ORDER BY.

La idea clave: el usuario no aporta texto, elige una opción de un conjunto que tú controlas. Lo que se concatena nunca sale de la entrada; sale de tu diccionario. Y como efecto secundario, el valor por defecto convierte un parámetro basura en un orden razonable en lugar de un error.

Cuando el SQL dinámico se construye dentro de PostgreSQL —en una función PL/pgSQL (10-04)— la herramienta es format() con sus marcadores de tipo:

%I aplica quote_ident: entrecomilla el identificador y neutraliza cualquier cosa rara que traiga. Nunca uses %s con entrada del usuario; %s es concatenación con otro nombre. Y aun con %I, lo correcto es validar antes contra la lista de tablas permitidas o contra information_schema: %I impide la inyección, pero no impide que alguien cuente las filas de una tabla que no le corresponde.

Ninguna capa basta sola; la buena noticia es que se suman.

Sobre los mensajes de error: en producción, el error completo de PostgreSQL le dice al usuario el nombre de las tablas, de las columnas y de las restricciones. Registra el detalle en el servidor, devuelve un texto genérico y un identificador que permita a soporte encontrar la traza; en desarrollo, al revés.

Aquí se cierran las promesas de 05-04, 09-05, 10-01 y 10-04. El modelo es más simple de lo que parece, con una idea central:

En PostgreSQL no hay "usuarios" y "grupos": solo hay roles. Un rol con LOGIN se comporta como un usuario; un rol sin LOGIN al que se conceden otros roles se comporta como un grupo. Es el mismo objeto.

Los privilegios se conceden con GRANT, se retiran con REVOKE y se aplican a distintos niveles:

Dos trampas que pillan a todo el mundo:

• USAGE sobre el esquema es imprescindible. Sin él, GRANT SELECT ON pedidos no sirve de nada: el rol tiene permiso sobre una tabla que no puede alcanzar. El error es permission denied for schema public y desconcierta porque el GRANT de la tabla existe.
• ALTER DEFAULT PRIVILEGES, o los objetos nuevos no heredan nada. Un GRANT SELECT ON ALL TABLES IN SCHEMA public afecta a las tablas que existen en ese momento. La tabla que crees mañana no estará incluida, y el fallo aparecerá en producción después del despliegue:

Ojo: ALTER DEFAULT PRIVILEGES se aplica a los objetos que cree el rol que ejecuta la orden. Si las migraciones las lanza tv_admin, hay que ejecutarlo como tv_admin (o con FOR ROLE tv_admin).

Son dos cosas distintas con el mismo nombre, y confundirlas es el clásico de la lección. PUBLIC es un pseudo-rol que significa "todos los roles que existan y existirán". public es el esquema por omisión donde viven las nueve tablas de TiendaVerde.

Históricamente, PUBLIC tenía CREATE sobre el esquema public, de modo que cualquier usuario podía crear objetos allí. PostgreSQL 15 lo corrigió, pero en bases creadas antes, o migradas, conviene comprobarlo y endurecerlo:

Y recuerda del módulo 10 que una vista solo protege si quitas el permiso sobre la tabla: GRANT SELECT ON v_clientes_publico no sirve de nada mientras el rol conserve SELECT ON clientes.

Tres roles de grupo, tres perfiles reales, y nadie conectándose como propietario de las tablas:

Comprobar qué tiene cada rol es tan importante como concederlo:

En psql, \dp pedidos da la misma información de forma compacta. La regla de oro: la aplicación nunca se conecta como superusuario ni como propietario de las tablas. Si web_prod es propietario, todos los REVOKE del mundo son decorativos: el propietario puede reconcedérselo todo.

Los permisos anteriores llegan hasta la tabla y la columna. Row Level Security (RLS) llega hasta la fila: permite que dos usuarios ejecuten SELECT * FROM pedidos y obtengan resultados distintos. El caso clásico: que cada comercial vea solo sus pedidos.

Con SET app.empleado_id = '4' al inicio de la sesión, el comercial Óscar (empleado 4) ve 4 pedidos —los números 2, 6, 10 y 16— y ningún otro, aunque escriba SELECT * FROM pedidos sin WHERE. Los diez pedidos web, con empleado_id NULL, no los ve nadie con esta política, porque NULL = 4 no es cierto: si deben verlos todos, la condición sería empleado_id = ... OR empleado_id IS NULL, y esa decisión hay que tomarla explícitamente.

Tres avisos. El propietario de la tabla y los superusuarios se saltan RLS por omisión (hace falta FORCE ROW LEVEL SECURITY). Las políticas se escriben por operación —FOR SELECT, FOR INSERT con WITH CHECK, FOR UPDATE, FOR ALL— y si no defines la de INSERT, no se puede insertar nada. Y el coste de rendimiento es real: la condición entra en todas las consultas, así que la columna de la política debe estar indexada. RLS brilla en multi-inquilino (empresa_id); para tres pantallas y un rol, suele bastar una vista.

Cierra 10-04. Por omisión una función se ejecuta con los permisos de quien la llama (SECURITY INVOKER). Con SECURITY DEFINER se ejecuta con los de quien la creó, lo que permite dar acceso controlado a datos que el usuario no puede leer: por ejemplo, que un analista obtenga la media salarial sin poder leer empleados.

La media salarial canónica del curso, 35 037,50 €, servida sin dar acceso a la tabla. Y ahora el riesgo, que es serio: una función SECURITY DEFINER corre con privilegios ajenos, así que si el atacante controla qué objetos resuelve dentro de ella, ejecuta código con esos privilegios. El vector es el search_path: si la función dice FROM empleados sin cualificar y el llamante ha puesto por delante un esquema suyo con una tabla empleados propia, la función leerá la del atacante.

Las cuatro reglas, y no son opcionales: (1) fija siempre SET search_path = public, pg_temp en toda función SECURITY DEFINER (o cualifica cada objeto: public.empleados); (2) REVOKE EXECUTE ... FROM PUBLIC y concede solo a quien deba, porque por omisión EXECUTE se concede a PUBLIC; (3) haz la función lo más pequeña posible y sin SQL dinámico dentro —y si lo hay, format('%I'/'%L') y lista blanca—; (4) úsala solo cuando haga falta: SECURITY INVOKER es el valor por omisión por una buena razón.

TiendaVerde es ficticia, pero su esquema tiene exactamente los datos que en un sistema real están regulados:

Las medidas que hay que conocer, sin entrar en materia jurídica:

• Cifrado en tránsito: TLS obligatorio en la conexión (sslmode=require o superior); sin él, credenciales y datos viajan en claro. En reposo: cifrado de disco o de volumen, y de las copias de seguridad, que es lo que más se olvida.
• Mínimo privilegio, que es lo del apartado 8: la mayoría de los analistas no necesita ver correos. Y registro de accesos a los datos sensibles, no solo de los cambios.
• Seudonimización para entornos de prueba: sustituir nombres y correos, desplazar fechas, alterar importes — con la advertencia de que una seudonimización mal hecha es reversible (un "hash del email" se revierte probando correos).
• Retención: los datos personales no se guardan para siempre. Hay que decidir cuánto y borrarlos o anonimizarlos después (05-04).

⚠️ Antes de exponer un sistema real: encarga una revisión de seguridad a un profesional (revisión de código, configuración y pruebas de intrusión) y contrasta el tratamiento de los datos personales con el responsable de protección de datos o la asesoría jurídica de tu organización. Esta lección te da el vocabulario y las prácticas mínimas; no sustituye ni a una auditoría ni a un análisis de cumplimiento.

Consultas. 1. ¿Todos los valores del usuario van como parámetros? Busca concatenaciones y f-strings con SQL dentro. 2. ¿Hay identificadores dinámicos (ORDER BY, nombre de tabla)? ¿Están resueltos con lista blanca o %I? 3. ¿Se escapan % y _ en las búsquedas con LIKE/ILIKE?

Permisos. 4. ¿La aplicación se conecta con un rol que no es superusuario ni propietario? 5. ¿Ese rol tiene solo lo que necesita, sin DELETE ni TRUNCATE gratuitos? 6. ¿Está puesto ALTER DEFAULT PRIVILEGES para las tablas futuras? 7. ¿Se ha revocado CREATE sobre el esquema public a PUBLIC? 8. ¿Las vistas "de seguridad" tienen revocado el permiso sobre la tabla base? 9. ¿Las funciones SECURITY DEFINER fijan search_path y tienen REVOKE ... FROM PUBLIC?

Datos y operación. 10. ¿La conexión usa TLS y están cifradas las copias de seguridad? 11. ¿Los entornos de prueba tienen datos ficticios o seudonimizados? 12. ¿Los mensajes de error de producción son genéricos, con el detalle en el registro? 13. ¿Se registran y revisan los accesos a datos sensibles y los errores de sintaxis repetidos? 14. ¿Hay fecha para la revisión externa antes de salir a producción?

• Creer que un dato numérico no es inyectable. WHERE id = " + entrada es inyectable sin usar ni una comilla. Parametriza siempre, no solo los textos.
• Usar un ORM y darlo por seguro. En cuanto aparece raw(), text() o createNativeQuery() con una f-string, la protección desaparece (11-05). Y dejar PDO con la emulación de preparadas activada: escapa en el cliente en lugar de usar preparadas reales.
• Conceder SELECT sin USAGE sobre el esquema. permission denied for schema public con el GRANT de la tabla ya hecho: falta GRANT USAGE ON SCHEMA. Y olvidar ALTER DEFAULT PRIVILEGES: todo funciona hasta que una migración añade una tabla y la aplicación deja de verla en producción.
• Confundir PUBLIC (el pseudo-rol "todos") con el esquema public. Un REVOKE ... FROM PUBLIC afecta a todos los roles, presentes y futuros.
• Crear una vista "de seguridad" y dejar el GRANT sobre la tabla. No protege nada. Y SECURITY DEFINER sin search_path fijado: es una escalada de privilegios de manual.
• Consejo: busca execute( seguido de una f-string o de un + en todo el repositorio. Es la revisión de seguridad más barata y encuentra la mayoría de los casos. Y prueba cada campo del formulario con ' y con --: si algo se rompe con una comilla, hay concatenación detrás.
• Consejo: escribe los GRANT en una migración, no a mano. Los permisos son parte del esquema y deben poder reconstruirse desde el repositorio (05-06).

Este endpoint devuelve los pedidos de un cliente:

(1) Señala las tres vías de inyección. (2) Reescríbelo correctamente. (3) ¿Por qué la tercera no se arregla igual que las otras dos?

Diseña los permisos para dos perfiles nuevos de TiendaVerde: tv_almacen (Irene, operaria) necesita ver los pedidos pagados y sus líneas, y actualizar el estado del pedido a enviado; tv_soporte (Marc, atención al cliente) necesita ver todo lo de un cliente, incluido su correo, y crear devoluciones. (1) Escribe los GRANT. (2) ¿Cómo impedirías que tv_almacen cambie el estado a cancelado? (3) ¿Qué le falta a tv_soporte para poder insertar en devoluciones?

Un compañero propone: "Damos SELECT sobre todo a los analistas, que son de confianza, y así no molestan pidiendo permisos". Rebate la propuesta con cuatro argumentos concretos referidos a TiendaVerde, y propón una alternativa que resuelva su problema real.

Solución 1

1. Las tres: cliente_id interpolado sin comillas —inyectable con 1 OR 1=1, y la que más se pasa por alto precisamente por "ser un número"—; estado interpolado dentro de comillas, inyectable cerrándolas; y orden, que es un identificador y no puede ser un parámetro.

3. Porque un parámetro es siempre un valor, nunca estructura. ORDER BY $1 ordenaría por la constante $1, no por la columna cuyo nombre contiene: el motor ya ha planificado la consulta cuando recibe el valor, y el orden es parte del plan. Por eso los identificadores se resuelven con lista blanca (o con %I si el SQL se construye dentro del servidor), que es una técnica distinta con el mismo objetivo: que la entrada del usuario nunca aporte texto SQL.

Solución 2

2. Un GRANT UPDATE (estado) deja cambiar la columna, pero no controla a qué valor. Eso es una regla de negocio y va en la base: un trigger BEFORE UPDATE (10-05) que rechace transiciones no permitidas, o un procedimiento sp_marcar_enviado al que se concede EXECUTE mientras se retira el UPDATE directo — la segunda opción es más limpia, porque expone la operación y no la columna. 3. Le falta el permiso sobre la secuencia —devoluciones_id_seq—, sin el cual un INSERT que deja generar el id falla con permission denied for sequence. Es el olvido más habitual al conceder INSERT, y por eso en el apartado 8 aparece un GRANT USAGE ON ALL SEQUENCES.

Solución 3

Los cuatro argumentos. (a) clientes.email y empleados.salario no son de confianza ni de desconfianza: son datos personales cuyo acceso debe estar limitado a quien los necesite para su trabajo, y un analista de ventas no los necesita. (b) La confianza no protege del accidente: una exportación a CSV, un portátil perdido o un panel compartido convierten un SELECT legítimo en una fuga. (c) La confianza no protege de la cuenta comprometida: si roban las credenciales de Daniel, el atacante hereda exactamente lo que Daniel tenía. (d) Sin ALTER DEFAULT PRIVILEGES y con "acceso a todo", cada tabla nueva —incluida una futura nominas— queda expuesta por omisión, que es justo lo contrario de lo que debe pasar.

La alternativa, que además resuelve su problema real (dejar de molestar pidiendo permisos): darles tv_lectura sobre las vistas de análisis, no sobre las tablas. Una capa de vistas v_* que excluya las columnas sensibles, con ALTER DEFAULT PRIVILEGES para que las vistas nuevas se concedan solas, y un SECURITY DEFINER para los pocos agregados que necesiten datos restringidos —como fn_salario_medio—. El analista gana autonomía y la exposición es mucho menor.

Esta lección cierra la mitad menos visible del curso y la que más caro se paga si falta:

• La inyección SQL ocurre porque el código y los datos viajan en la misma cadena. Con la entrada ' OR '1'='1, un buscador concatenado pasa de devolver 2 productos a devolver los 19 activos; con -- de por medio, los 20, incluido el descatalogado. Y el mismo fallo hace que O'Connor rompa la consulta. La defensa es una sola y es total: consultas parametrizadas. El servidor analiza y planifica antes de ver los valores, así que un valor no puede convertirse en código. Igual en psycopg, JDBC, PDO y node-postgres, y en SQL puro con PREPARE/EXECUTE.
• No son defensas: escapar a mano, las listas negras, ocultar los errores, validar en el navegador o "usar un ORM". Y los identificadores no se parametrizan: van con lista blanca, o con format('%I') / quote_ident dentro del servidor. Nunca %s.
• Permisos: en PostgreSQL todo son roles; GRANT/REVOKE sobre base, esquema, tabla, columna, secuencia y función; USAGE sobre el esquema es imprescindible y ALTER DEFAULT PRIVILEGES es lo que hace que los objetos futuros hereden. PUBLIC (todos los roles) no es el esquema public, y una vista solo protege si se revoca el permiso sobre la tabla.
• El diseño de TiendaVerde: tv_lectura para analistas sin email ni empleados, tv_app sin DELETE ni DDL, tv_admin solo para migraciones. Y la regla de oro: la aplicación nunca se conecta como superusuario ni como propietario.
• RLS filtra por fila —el comercial 4 ve sus 4 pedidos y ninguno más— a cambio de una condición en todas las consultas y de una depuración más difícil; SECURITY DEFINER presta privilegios y exige SET search_path y REVOKE EXECUTE FROM PUBLIC. Y los datos personales: identificar qué columnas lo son, TLS en tránsito, cifrado en reposo y de las copias, seudonimización en pruebas, retención — con la revisión por un profesional de seguridad y por el responsable legal antes de exponer nada real.

Con esto el sistema está protegido y es mantenible. Toca sacarle valor. En la lección siguiente, SQL para análisis de datos, verás el oficio del analista: el flujo que va de la pregunta de negocio a la métrica bien definida —y por qué la mitad de los errores de análisis son de definición y no de SQL: ¿"ventas" incluye los portes?, ¿y el pedido cancelado?—; las métricas fundamentales de TiendaVerde calculadas una a una; el análisis temporal con acumulados y medias móviles; la segmentación y el Pareto de clientes y productos; las cohortes con su advertencia honesta sobre el tamaño de muestra; la presentación con CASE y con crosstab, cerrando la promesa de 06-05; y dónde encaja SQL frente a Python y a las herramientas de BI.