ClickHouse Security Review
ClickHouse’s default account has full rights and sits outside SQL-driven access control until switched on. We test that account, your roles and grants, row policies, network exposure and Cloud access controls. CREST-certified testers, fixed price from £2,620 for a 2-day single-instance 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.”
ClickHouse Cloud sets the IP access list for both a new service and a new API key to Allow from anywhere by default, so every project starts open to the whole internet until you restrict it to specific addresses.
Why ClickHouse security comes down to the default account, roles and what the network and Cloud access lists expose
ClickHouse’s own documentation on access rights states plainly that the server ships a default user account which isn’t restricted by SQL-driven access control and holds all rights and permissions, and that this account is used whenever a client connection or a distributed query doesn’t specify a username. The documented route out is to enable SQL-driven access control, log in as the default user to create named accounts and an administrator, then restrict the default account and switch its own access control back off, a sequence we check has actually been completed rather than left half finished. Roles built with CREATE ROLE and privileges assigned with GRANT are additive, so we map every role a user holds rather than trusting the narrowest one to apply.
Row-level filtering works through row policies, and ClickHouse’s own documentation is direct that they only make sense with read-only access, since a user who can modify a table or copy partitions between tables defeats the restriction outright. The same read-only assumption has a second gap: ClickHouse’s documentation on permissions for queries states that BACKUP is not restricted by the readonly setting at any value and that readonly = 2 still permits RESTORE, so a session set up to be read-only can still write data through either route. We test what a read-only session can actually still do, and cover the same row and tenant separation questions in more general form on our database security review.
On self-managed ClickHouse, the documentation on network ports confirms a fresh install listens on port 8123 for HTTP and port 9000 for the native protocol, with HTTPS on 8443 only once you enable it, and ClickHouse’s TLS configuration guide is explicit that its certificate setup steps do not apply to ClickHouse Cloud, where the same procedure is automated. ClickHouse Cloud moves the exposure question to its IP access lists, which default to Allow from anywhere for both a new service and a new API key, and to its organisation, service and SQL console roles, which sit as separate layers above the database’s own users and roles. For the wider family of cache and streaming platforms this scope splits from, see our NoSQL, cache and streaming security review.
SCOPE
What we pen test on a ClickHouse instance
Default User Account and SQL-Driven Access Control
ClickHouse ships a default user account that isn’t restricted by SQL-driven access control and holds all rights and permissions, and that account is used whenever a client connection or a distributed query doesn’t specify a username. We test whether SQL-driven access control has actually been enabled and the default account restricted, or whether it was left as the unrestricted fallback the documentation describes.
SQL-Driven Access Control vs Configuration Files
ClickHouse supports two ways to manage users and roles, SQL statements or the server’s XML configuration files, and its documentation is explicit that the same access entity cannot be managed by both methods at once. We test which method is actually in use for each account and role, and flag a user or role still defined in configuration files that a team believes was migrated to SQL-driven management.
Roles, Grants and Privilege Inheritance
Roles created with CREATE ROLE gain their privileges through GRANT, and a user account can hold several roles at once with no built-in mechanism collapsing them back down to the narrowest one. We test every role a user account holds against what that user actually needs, not just the role it was assigned when the account was first created.
Row Policies and the Read-Only Requirement
A row policy filters which rows a user or role can read from a table, but ClickHouse’s own documentation states plainly that a row policy only restricts access if the user is read-only, since anyone who can modify the table or copy partitions between tables can bypass it entirely. We test whether every user covered by a row policy is genuinely restricted to read access, and cover the same row and tenant separation questions for other engines on our database security review.
What the readonly Setting Does Not Stop
The readonly setting blocks writes to persistent tables at any value above zero, but ClickHouse documents that BACKUP is not restricted by readonly at any level and that readonly = 2 still permits RESTORE, which can create a table and load data into it. We test what a session configured as read-only can still do through backup and restore commands, not just through ordinary INSERT and UPDATE statements.
Network Exposure and Default Ports
A fresh ClickHouse install listens on port 8123 for HTTP and port 9000 for the native protocol by default, with separate ports for the MySQL and PostgreSQL emulation interfaces and for inter-server communication. We test which of these ports are reachable from outside the application network, and whether each one needs to be exposed at all for the deployment in scope.
TLS Configuration for Self-Managed Deployments
HTTPS on port 8443 has to be enabled rather than being on by default, and ClickHouse’s own TLS configuration guide states outright that its certificate setup does not apply to ClickHouse Cloud, where the same process is automated for you. We test what a self-managed deployment’s actual TLS configuration allows once certificates have been issued, including whether plain HTTP or the unencrypted native protocol port is still reachable alongside it.
ClickHouse Cloud IP Access Lists
When you create a ClickHouse Cloud service or an API key, the IP access list defaults to Allow from anywhere, and ClickHouse’s own documentation recommends restricting it as soon as possible. We test what is actually in the access list for every service and API key in scope against what the deployment needs to reach it.
Cloud API Keys and Rate Limits
ClickHouse Cloud API keys manage organisation and service settings through the Cloud API, and ClickHouse documents a limit of 100 keys per organisation with each key capped at 10 requests over a 10-second window. We test what each API key is actually scoped to manage, and whether a key created for one integration has since been reused more widely than intended.
SQL Console Sessions and Console Roles
A ClickHouse Cloud SQL console session authenticates with an X.509 certificate that is rotated automatically and removed when the session ends, sitting above separate layers of organisation, service and SQL console roles that are distinct from the database’s own users and roles. We test whether console role assignments match who actually needs administrative reach, and whether a database role granted to a console user’s session is broader than the equivalent database user would get.
OUR PROCESS
ClickHouse Security Review: From Scope to Attestation
Scope and Access
We agree which ClickHouse instances, Cloud services and API keys are in scope, plus a database user for every privilege tier you want tested and, where relevant, a Cloud console role to review organisation and service settings.
Access Control Mapping
We map every role, database user, row policy and IP access list entry against who or what actually needs that level of access, on self-managed instances and in ClickHouse Cloud.
Manual Testing
A CREST-certified tester manually tests the default account and SQL-driven access control, row policies and readonly boundaries, network exposure and TLS configuration, and Cloud IP access lists and API key scope, 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 ClickHouse 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 ClickHouse 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 4 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote4 to 6 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 ClickHouse 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 ClickHouse 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 ClickHouse deployment?
We need at least one authenticated database user for every privilege tier in scope, from an ordinary application account through to a role that can query user, role and row policy configuration on a self-managed instance, or the equivalent console role in ClickHouse Cloud. Read access to Cloud organisation and service role assignments speeds up the review, though we can test with database-level access alone.
Will testing touch live data?
We test the databases and tables you nominate, working against your actual users, roles and row policies rather than a copy, so we agree exclusions such as destructive commands or production replica targets before testing starts. We do not export real customer data or run destructive tests without that agreement in writing.
Do you test self-managed ClickHouse and ClickHouse Cloud the same way?
The underlying questions are the same: who can authenticate, what role or row policy applies to them, and what the network or IP access list actually exposes. What differs is the boundary, since ClickHouse Cloud manages the host, TLS certificates and the console roles above the database, so we confirm during scoping exactly what you control on your Cloud plan and test to that boundary.
What is out of scope for a single-instance ClickHouse review?
We never test ClickHouse’s own source code, the underlying host or hypervisor of a managed Cloud service, or ClickHouse Cloud’s shared infrastructure, and a separately hosted application that happens to query the instance is scoped and quoted on its own. We test the default account, roles, row policies, network configuration, TLS, IP access lists and API key scope for the instance or service you nominate.
Does ClickHouse have a policy on customer penetration testing?
ClickHouse publishes extensive documentation on access control, network configuration and Cloud security. We confirm ClickHouse’s current terms for testing your own instance or Cloud service during scoping and test within them for the duration of the engagement.
How long does a ClickHouse security review take?
A single ClickHouse instance or Cloud service, with a small number of databases and a limited set of roles, sits in our 2-day single-instance scope, with a report typically landing around 5 working days after kickoff. More databases, multiple Cloud services, or a mix of self-managed and Cloud deployments moves into a larger scope with more testing days.
What if we also run MongoDB, Redis or Kafka alongside ClickHouse?
Those sit on our NoSQL, cache and streaming security review, which covers MongoDB, Redis, Kafka and Elasticsearch under the same price parent as this ClickHouse scope. We quote a combined engagement covering every platform you run rather than treating each one as a separate scoping call.
Are your testers CREST certified?
Yes. Every ClickHouse 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 ClickHouse review
ClickHouse’s default account has full rights and sits outside SQL-driven access control until switched on. We test that account, your roles and grants, row policies, network exposure and Cloud access controls. CREST-certified testers, fixed price from £2,620 for a 2-day single-instance scope, quoted within 24 hours.
