rules-postgresql

Hardcoded PostgreSQL connection string or password in source code. Credentials committed to VCS are exposed to anyone with repository access and in CI logs. Load the connection string from an environment variable (DATABASE_URL) or a secrets manager instead.

COPY TO/FROM with an absolute file path runs as the PostgreSQL superuser and can read or overwrite arbitrary files on the database server (CWE-22, CVE-2018-1115 class). Use COPY ... TO STDOUT / FROM STDIN piped through the application layer instead, or restrict with pg_read_file/pg_write_file roles.

pg_read_file(), pg_read_binary_file(), and pg_ls_dir() expose the filesystem of the database server to SQL-level callers. If the query is reachable from user input this is a server-side file read vulnerability. Restrict execution to superuser/pg_monitor roles and never expose these functions to application service accounts.

Granting SUPERUSER privilege bypasses all PostgreSQL access controls — a SUPERUSER can read any table, write any file the OS process can reach, and execute arbitrary OS commands via COPY. Use fine-grained GRANT statements on specific schemas and tables instead.

SQL query assembled via string concatenation or template interpolation with request data — direct SQL injection risk (CWE-89). Use parameterised queries: db.query('SELECT ... WHERE id = $1', [userId]) in pg/node-postgres, or an ORM. Never interpolate user-controlled values into SQL strings.

Dynamic EXECUTE in PL/pgSQL executes a string as SQL. If the string includes any user-supplied input without parameterisation, this is a first-class SQL injection vector (CWE-89). Use parameterised statements or EXECUTE ... USING $1 with bound parameters instead of string concatenation.