From Dev to Prod: Securing Postgres the Right Way
summary
Covers concrete fixes: a CVE-2025 SQL injection caused by overreliance on escapeString and client-side sanitization, plus a case where a malicious public calculate_bonus returns “10_000_000” by abusing a weak search_path and SECURITY DEFINER calls. Shows applied controls: revoke public schema, create app_read/app_write roles, harden search_path to admin, pg_catalog, use pg_hba.conf with hostssl, scram‑sha‑256 and IP whitelist 10.0.0.0/24. Notes Postgres 17’s pg_maintain and safer search_path, incremental backups, and Postgres 18’s OAuth support.
AI-written summary · about
chapters (10)
- 0:00Music & introduction
- 3:06Common PostgreSQL security blind spots
- 5:45SQL injection case study breakdown
- 8:13Least privilege and role boundaries
- 10:25Schema isolation for safer deployments
- 12:25How search_path becomes a security risk
- 15:02Exploiting security definer functions
- 18:16Protecting data in transit and at rest
- 22:16Postgres 17 and 18 security upgrades
- 25:21Final security checklist and takeaways
related talks
07mAll about Postgres security
50mSecuring PostgreSQL
32mEnhancing Security in PostgreSQL
40mPostgreSQL Security for Application Developers
38mPostgreSQL and DevSecOps: Ensuring database security
32mPostgreSQL Security: Defending Against External Attacks
35mSecuring PostgreSQL From External Attack
45mSecurity Attacks on PostgreSQL