Responderé primero a tu pregunta de "búsqueda secundaria":
tienes toda la razón con tus preocupaciones e inquietudes, y todos los que diseñan una aplicación deberían pensar en las mismas cosas. Todo lo demás es descuidado y descuidado.
Para mitigar el daño que puede causar un ataque de inyección SQL exitoso, definitivamente debe emplear el principio de privilegio mínimo.
Debería ser bastante simple configurar un sistema que coincida con sus requisitos.
Usaré los nombres de objeto de su ejemplo, excepto que usaré guiones bajos en lugar de menos. Es una buena práctica usar solo letras minúsculas, guiones bajos y números en los nombres de los objetos, ya que le facilitará la vida.
/* create the database */
\c postgres postgres
CREATE DATABASE test_database WITH OWNER app_admin;
\c test_database postgres
/* drop public schema; other, less invasive option is to
REVOKE ALL ON SCHEMA public FROM PUBLIC */
DROP SCHEMA public;
/* create an application schema */
CREATE SCHEMA app AUTHORIZATION app_admin;
/* further operations won't need superuser access */
\c test_database app_admin
/* allow app_user to access, but not create objects in the schema */
GRANT USAGE ON SCHEMA app TO app_user;
/* PUBLIC should not be allowed to execute functions created by app_admin */
ALTER DEFAULT PRIVILEGES FOR ROLE app_admin
REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC;
/* assuming that app_user should be allowed to do anything
with data in all tables in that schema, allow access for all
objects that app_admin will create there */
ALTER DEFAULT PRIVILEGES FOR ROLE app_admin IN SCHEMA app
GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_user;
ALTER DEFAULT PRIVILEGES FOR ROLE app_admin IN SCHEMA app
GRANT SELECT, USAGE ON SEQUENCES TO app_user;
ALTER DEFAULT PRIVILEGES FOR ROLE app_admin IN SCHEMA app
GRANT EXECUTE ON FUNCTIONS TO app_user;
Pero si toma el principio de menos en serio, debe otorgar permisos de mesa individualmente y, p. no permitir app_user para DELETE y UPDATE datos en tablas donde no es necesario que el usuario lo haga.
