Je vais d'abord répondre à votre question de "quête parallèle" :
vous avez tout à fait raison avec vos inquiétudes et vos préoccupations, et tous ceux qui conçoivent une application devraient penser aux mêmes choses. Tout le reste est bâclé et négligent.
Pour atténuer les dommages pouvant être causés par une attaque par injection SQL réussie, vous devez absolument utiliser le principe du moindre privilège.
Il devrait être assez simple de mettre en place un système qui correspond à vos besoins.
J'utiliserai les noms d'objet de votre exemple, sauf que j'utiliserai des traits de soulignement au lieu de moins. Il est recommandé de n'utiliser que des lettres minuscules, des traits de soulignement et des chiffres dans les noms d'objets, car cela vous facilitera la vie.
/* 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;
Mais si vous prenez le principe du moins au sérieux, vous devez accorder des autorisations de table individuellement et par ex. ne pas autoriser app_user pour DELETE et UPDATE données dans des tableaux où l'utilisateur n'a pas besoin de le faire.
