PostgreSQL Security Review
PostgreSQL does exactly what your roles and policies allow, and table owners bypass row-level security by default. We review roles, row-level security, schema privileges and network access. CREST-certified testers, fixed price from £2,740 for a 2-day single-system scope, quoted within 24 hours.
- Unlimited retesting
- Unlimited pre-retesting
- No hidden fees
“I would highly recommend EJN Labs to any organisation seeking reliable, detailed, and well-managed penetration testing services, particularly for government or enterprise-level projects.”
“There wasn’t another company we could find that could deliver what we needed in the timeframe we needed. The client loved it, and we got instant ROI from the engagement.”
Row security policies decide which rows a role can see or change, but PostgreSQL applies them per table, per role and per command, and by default the table’s own owner sits outside them.
Why PostgreSQL access comes down to roles, policies and who owns the table
PostgreSQL’s own documentation sets out role attributes as the base layer of access: a database superuser bypasses all permission checks except the right to log in, and every new role gets the INHERIT attribute by default, so it automatically uses the privileges of any role it is a member of. A role created for one application can end up a member of a group meant for administrators, or carry the separate BYPASSRLS attribute that lets it skip row security entirely, and neither change is visible anywhere except the role’s own definition.
Row security narrows access further, but only where it has been switched on. PostgreSQL’s documentation is explicit that a table’s owner is typically not subject to its own row security policies, so a table can carry a correct-looking policy while the account your application actually connects as, if it happens to own that table, reads and writes every row regardless. ALTER TABLE has a dedicated FORCE ROW LEVEL SECURITY clause to close that gap for the owner, but a superuser or a role with BYPASSRLS bypasses row security either way, so which accounts hold those attributes matters as much as the policies themselves.
Schema privileges sit underneath all of this: PostgreSQL 15 changed the default so ordinary users can no longer create objects in the public schema without being granted that privilege, but a database upgraded from an earlier version keeps its original, wider grant until someone revokes it. Where PostgreSQL runs also changes what we can test: on a managed service such as Amazon RDS or Aurora, Azure Database for PostgreSQL, Google Cloud SQL or Supabase, the provider controls the host and most of the surrounding operational configuration, while your roles, policies, schema privileges and application code remain yours to secure. For estates running several database engines, see our wider database security review.
SCOPE
What we review in a PostgreSQL database
Roles, Membership and Inheritance
PostgreSQL gives every new role the INHERIT attribute by default, so a role automatically uses the privileges of any role it is a member of without running SET ROLE, though special attributes such as LOGIN, SUPERUSER, CREATEDB and CREATEROLE are never inherited this way and still need an explicit SET ROLE to use. We map every role’s membership chain against what it is actually used for, and flag a service or application role that has ended up a member of a broader administrative group by inheritance.
Superuser Status and the BYPASSRLS Attribute
A PostgreSQL superuser bypasses all permission checks except the right to log in, and a role can separately be given the BYPASSRLS attribute, set through CREATE ROLE, to skip row security policies without holding full superuser status. We test which roles carry either attribute, whether an application or reporting account holds one it no longer needs, and whether that access matches who is meant to have unrestricted reach into the database.
Row Security Policies and Table Owner Bypass
Row security policies restrict which rows a role can select, insert, update or delete, but PostgreSQL’s documentation notes that a table’s owner is typically not subject to its own row security policies, and ALTER TABLE offers a dedicated FORCE ROW LEVEL SECURITY clause specifically to apply them to the owner too. We test whether every table that relies on row security for tenant or customer separation has FORCE set where it is needed, and whether a policy’s USING expression and its check condition actually cover every command it is meant to restrict.
Public Schema and Default Privileges
PostgreSQL 15 changed the default configuration so ordinary users can no longer create objects in the public schema unless they are explicitly granted CREATE on it, but a database upgraded from PostgreSQL 14 or earlier keeps its original grant of CREATE on public to every user until someone revokes it by hand. We test the CREATE and USAGE privileges actually set on every schema in scope against who is meant to be able to create objects there, not just the version’s default configuration.
Client Authentication in pg_hba.conf
pg_hba.conf holds a sequence of records, each specifying a connection type, client address range, database, role and authentication method, and PostgreSQL applies the first record that matches an incoming connection rather than the most restrictive one available. We review every host, hostssl and local record in scope for an authentication method weaker than the connection deserves, such as trust or a broad address range left over from testing, and for a record placed high enough in the file to override a stricter one below it.
Listen Addresses, Network Exposure and SSL/TLS
listen_addresses controls which network interfaces PostgreSQL accepts connections on before pg_hba.conf is ever consulted, and defaults to localhost so only local loopback connections are possible until it is changed. The ssl parameter is a separate setting again, off by default, and has to be enabled before any connection can be encrypted with TLS at all. We check what listen_addresses is actually set to on every instance in scope, whether SSL is enforced for connections that leave a trusted network, and whether a port reachable from the public internet was intended to be.
Extensions, Untrusted Languages and dblink/postgres_fdw
An untrusted procedural language such as PL/Perlu or PL/Pythonu runs with the same operating system privileges as the PostgreSQL server process, and PostgreSQL grants USAGE on a trusted procedural language to every role by default, a default that does not extend to untrusted languages. Extensions such as dblink and postgres_fdw let a function inside the database open a connection out to another PostgreSQL server using credentials stored in a separate user mapping rather than the calling query. We review every installed extension and procedural language against who can create functions with it, and how a dblink or postgres_fdw connection out to another system is authenticated.
SECURITY DEFINER Functions and search_path
A SECURITY DEFINER function runs with the privileges of the role that owns it rather than the role that calls it, and PostgreSQL’s own documentation for CREATE FUNCTION recommends setting search_path on the function itself to exclude any schema an untrusted user can write to, naming pg_temp last since the temporary-table schema is searched first by default and is normally writable by anyone. We test installed SECURITY DEFINER functions for a fixed search_path and for logic that could be hijacked by an object created earlier in an unset or overly broad search path.
Backup and Replication Access
PostgreSQL’s CREATE ROLE command includes a dedicated REPLICATION option, and a role needs that attribute, in addition to whatever pg_hba.conf allows for its connecting address, before it can open a streaming replication connection or run a tool such as pg_basebackup against the server. We test who holds REPLICATION access, where backups are written to and who can read them, and whether a replica or backup copy is held to the same access controls as the primary database.
Managed PostgreSQL: RDS, Aurora, Azure, Cloud SQL and Supabase
On a managed service the provider controls the host operating system and most of the operational configuration around it: Amazon RDS and Aurora offer IAM database authentication, issuing a short-lived token in place of a password, and encrypt storage, logs, backups and snapshots through AWS KMS; Azure Database for PostgreSQL adds Microsoft Entra authentication and network controls such as private endpoints and firewall rules; Google Cloud SQL replaces a customer-managed pg_hba.conf with authorized networks and a chosen SSL enforcement mode, and grants new built-in-authentication users a cloudsqlsuperuser role with limited superuser privileges rather than true superuser; and Supabase runs a service_role with the BYPASSRLS attribute alongside your own row security policies. We test the roles, policies, schema privileges and network configuration you control on whichever of these you run, confirming with you during scoping exactly what the provider manages instead.
OUR PROCESS
PostgreSQL Security Review: From Scope to Attestation
Scope and Access
We agree which PostgreSQL instances, databases and schemas are in scope, plus a role for every privilege tier you want tested and, where relevant, an admin or cloud console account for the managed service it runs on.
Role and Privilege Mapping
We map every role’s membership and inheritance chain, row security policies, schema privileges and installed extensions against who should actually hold that access.
Manual Testing
A CREST-certified tester manually tests authentication configuration, row security policies, SECURITY DEFINER functions, and extension and replication access, chaining findings where they compound.
Attestation and Retest
You get a technical report with CVSS scores and reproduction steps, a walkthrough call, a free retest once fixes are deployed, and an attestation letter for auditors.
CREDENTIALS
Verified Accreditations Auditors Accept
Every credential below is independently verifiable. UK procurement teams, FCA supervisors, ISO 27001 / SOC 2 auditors, and cyber insurance underwriters all recognise these standards.
GET YOUR QUOTE
Get a CREST PostgreSQL pen test quote in 24 hours
A fixed-price quote back in one business day, from a named CREST assessor. No sales pipeline, no chasing.
- CREST and IASME accredited. Testing your auditors and clients already recognise.
- Fast-track testing within 24 hours where required. Free retest of every fix included.
- Live findings via your client portal, not a four-week PDF.
- Fixed price from £3,500 for a single-role, single-app scope, agreed up front. Most engagements run £5,000 and up. No day-rate surprises.
Dan WilcocksonFounder, CelloriUnder NDA Further named references available on a scoping call.
- We reply within one business day with a fixed-price quote from a named CREST assessor.
- You approve the scope and we book a start date, usually within 24 hours.
- Live findings land in your client portal as we test, with a free retest of every fix.
Get your fixed pen test quote in 24 hours
Quote request received
We will reply within one business day with your fixed-price quote from a named CREST assessor.
Your data stays with us. No newsletter signup.
or book a 20-min scoping call first
We reply within one business day. Your data stays with us. No newsletter signup.
COMPLIANCE READY
Reports Mapped to Every Framework
Findings are written so your team can reference the report against each framework without translation work.
ISO 27001:2022
Annex A.8.8 management of technical vulnerabilities plus A.5.15-5.18 and A.8.2-8.5 access control validation.
SOC 2 Type I & II
CC6 logical access, CC7 system operations, CC8 change management evidence.
PCI DSS
Requirement 11.4 application penetration testing across cardholder data environments, including ecommerce penetration testing for online retail platforms.
FCA SYSC
SYSC 4.1.1R, 6.1.1R, 13 mapped to each finding for FCA-regulated firms.
UK GDPR
Article 32 effectiveness testing, customer-data security controls, ICO-acceptable evidence.
Cyber Essentials Plus
Direct certification through our IASME body status, single-vendor delivery.
PRICING
Transparent PostgreSQL Security Review Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
2 to 3 testing days
Single user role, basic CRUD application, marketing website with auth. Around 5 working days from kickoff to report.
Get a fixed quote3 to 5 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote5 to 8 testing days
Multi-tenant platform, complex authorisation matrix, integration-heavy applications. Around 15 to 20 working days from kickoff to report.
Get a fixed quoteSECTORS
Sectors We Test PostgreSQL For
Sector-specific scoping for regulated UK organisations.
Fintech & FCA-Regulated
FCA SYSC, Open Banking FAPI 1.0, PSD2 SCA, payment-flow scrutiny, KYC/AML testing.
Fintech sector pageSaaS Companies
SOC 2 Type I & II evidence, multi-tenant boundaries, role escalation, customer-tenant isolation.
SaaS sector pageLaw Firms
SRA Cyber Standard, privileged data, conveyancing fraud defence, partner-tier procurement.
Law firm sector pageHealthcare
NHS DTAC, DSP Toolkit v6, UK GDPR Article 32, EHR systems, telehealth platforms.
Healthcare sector pageInsurance
FCA / PRA Operational Resilience, cyber underwriting, claims data, broker portals.
Insurance sector pagePublic Sector
CCS / G-Cloud framework, NCSC-aligned, citizen-facing services, PSN-compliance scrutiny.
Public sector pageWHY EJN LABS
What You Get From PostgreSQL Security Review
Six concrete differentiators competitors don’t all match.
CREST-Certified Testers, Verifiable
Every test by a CREST-certified pen tester (CRT, CCT APP, CCT INF where applicable). Verify our company status at crest-approved.org.
24-Hour Startup, Where Required
From signed scope to active testing in a single business day for incident response, audit deadlines, or regulator-driven timelines.
Live Findings, Not 4-Week PDFs
Critical issues reported during testing through your client portal. Your team remediates while testing continues.
Audit-Ready Reports
Executive summary plus full technical report with CVSS scores and explicit framework mappings (ISO 27001, SOC 2, PCI DSS, FCA SYSC).
Free Retests, Standard
Verify remediation of every finding before close-out. Letter of attestation for audit submission included. Most competitors charge £1,500-£3,000 per retest.
UK-Based CREST Testers
Every engagement performed by vetted, UK-based CREST-certified testers, matched to your needs, security clearance, and compliance scope.
FAQ
Frequently Asked
What access do you need to test our PostgreSQL database?
We need at least one authenticated role for every privilege tier in scope, from an ordinary application role through to a role that can query pg_roles, pg_policies and installed extensions for configuration review. If a superuser or cloud console account is available we use it to confirm configuration rather than to run the manual test itself.
Will testing touch live data?
We test the databases and schemas you nominate, working against your actual roles, row security policies and schema structure rather than a copy, so we agree exclusions such as destructive statements, bulk data changes or production replication targets before testing starts. We do not run destructive tests or export real customer data without that agreement in writing.
How long does a PostgreSQL security review take?
A single PostgreSQL instance with a small number of databases in scope sits in our 2-day single-system scope, with a report typically landing around 5 working days after kickoff. More databases, schemas, or a mix of self-hosted and managed instances, moves into a larger scope with more testing days.
Do you test self-hosted and managed PostgreSQL the same way?
The testing questions are the same: roles, row security, schema privileges, authentication and extensions. What differs is the boundary, since a managed service such as RDS, Aurora, Azure Database for PostgreSQL, Cloud SQL or Supabase keeps the host and much of the operational configuration under the provider, so we confirm during scoping exactly what you control on your plan and test to that boundary.
What is out of scope for a single-system PostgreSQL review?
We never test the underlying host, hypervisor or infrastructure of a managed PostgreSQL service, or PostgreSQL’s own source code, and a separate connected system such as an identity provider or a backup platform is scoped and quoted separately. We test the roles, policies, schema privileges, authentication configuration and extensions configured on the instance and databases you nominate.
Do your cloud provider’s rules restrict what you can test?
Yes, where PostgreSQL runs on a managed cloud service. AWS, Microsoft Azure and Google Cloud all allow customers to run security assessments against their own cloud resources without needing prior approval, though each publishes its own rules on activities that need extra sign-off, such as AWS requiring approval for Command and Control testing. We confirm the current version of the relevant provider’s rules during scoping and test to them exactly.
Do you test installed extensions such as dblink or postgres_fdw?
Yes, reviewing which extensions and procedural languages are installed, who can use them, and how a dblink or postgres_fdw connection to another server is authenticated, is part of the standard engagement. Testing the extension’s own source code, rather than how it has been installed and used in your database, is out of scope.
Are your testers CREST certified?
Yes. Every PostgreSQL engagement is carried out by UK-based, CREST-certified testers, and your report and attestation letter are recognised by auditors and insurers accordingly.
20+ CREST-accredited testing services in one place
Web, mobile, API, cloud, AI, infrastructure, red team. Pick the test that fits your environment.
Get a fixed price for your PostgreSQL review
PostgreSQL does exactly what your roles and policies allow, and table owners bypass row-level security by default. We review roles, row-level security, schema privileges and network access. CREST-certified testers, fixed price from £2,740 for a 2-day single-system scope, quoted within 24 hours.
