Apache Cassandra Security Review
Apache Cassandra ships with authentication and authorisation disabled, so a fresh cluster accepts any connection and grants every permission by default. We test authentication, role permissions, network encryption and access restrictions. CREST-certified testers, fixed price from £2,620 for a 2-day single-cluster 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.”
Cassandra’s own documentation names TLS/SSL encryption, client authentication and authorisation as its three core security components, and states plainly that by default all three ship disabled. Out of the box that combination presents a large attack surface, and client authentication alone is not enough to close it.
Why Apache Cassandra security comes down to what ships switched off
Cassandra’s own security documentation is direct about what ships switched off: the authenticator setting defaults to AllowAllAuthenticator, which performs no authentication checks and requires no credentials, and the authorizer defaults to AllowAllAuthorizer, which grants every permission to every role and must remain paired with AllowAllAuthenticator. Switching on PasswordAuthenticator brings a fresh install’s own default superuser with it: the setup guide logs in with cqlsh -u cassandra -p cassandra and recommends creating a replacement superuser before disabling that account, a step the documentation calls optional but highly recommended. We test whether authentication and authorisation are enabled at all, and whether that default account is still live once they are.
Encryption follows the same pattern. Cassandra’s documentation on inter-node encryption sets internode_encryption to none by default, so traffic between nodes stays unencrypted until it is changed to rack, dc or all, and client-to-node encryption works the same way round: if neither the enabled nor optional setting in client_encryption_options is switched on, every client connection is unencrypted. Two further settings decide where a role can log in from at all: network_authorizer, which can restrict a role to specific data centres, and cidr_authorizer, which can restrict a role to specific CIDR groups, both default to their AllowAll implementation, so by default any role can authenticate from any data centre or network. We test what the deployment’s actual encryption and login-restriction settings allow once opened up for real traffic, not what a default installation ships with.
Once authorisation is switched on, permissions follow a strict hierarchy. Cassandra’s CQL permissions documentation structures data access as ALL KEYSPACES down through KEYSPACE to TABLE, and states that a permission granted higher up the chain flows down automatically, so a single GRANT SELECT ON ALL KEYSPACES quietly grants read access to every table in every keyspace a role will ever see. We map every granted permission against what a role actually needs, at the keyspace and table scope Cassandra documents rather than the broader grant that was easiest to issue at setup. For the wider family of NoSQL, cache and streaming platforms this scope splits from, see our NoSQL, cache and streaming security review.
SCOPE
What we review in an Apache Cassandra cluster
Authentication and the Default AllowAllAuthenticator
Cassandra’s authenticator setting defaults to AllowAllAuthenticator, which its own documentation states performs no authentication checks and therefore requires no credentials at all. Switching to PasswordAuthenticator means editing cassandra.yaml and restarting the node, and Cassandra’s documentation notes that PasswordAuthenticator also requires the use of CassandraRoleManager. We test whether authentication is actually enabled on every node in the cluster you nominate, not assumed from a configuration file that was correct on day one.
Authorisation and the Default AllowAllAuthorizer
The authorizer setting defaults to AllowAllAuthorizer, which grants every permission to every role and, per Cassandra’s own documentation, must be used if AllowAllAuthenticator is the configured authenticator. CassandraAuthorizer implements real permission management through GRANT PERMISSION and REVOKE PERMISSION statements once switched on, storing what it grants in the system_auth keyspace. We test whether authorisation is enabled at all, and whether the permissions a role actually holds match what CassandraAuthorizer says it was granted.
The Default Superuser Account
A fresh Cassandra install ships with a default superuser role, and the setup documentation logs into it directly with cqlsh -u cassandra -p cassandra before recommending operators create a separate superuser and then disable that default account with ALTER ROLE cassandra WITH SUPERUSER = false AND LOGIN = false. The documentation calls this step optional but highly recommended. We test whether the default account is still enabled on the cluster you nominate, and whether the roles that replaced it were built with the same broad access.
Permission Scope Across Keyspaces and Tables
Cassandra’s permissions documentation structures data access as a hierarchy running from ALL KEYSPACES down through KEYSPACE to TABLE, and states that a permission granted higher up the chain flows down automatically, so granting SELECT on ALL KEYSPACES grants it on every table in every keyspace without a separate statement. We test whether a role’s granted scope matches what it actually needs, and flag a cluster-wide grant that was only ever meant to cover one keyspace or table.
Inter-node Encryption
Inter-node encryption is controlled by the internode_encryption setting in server_encryption_options, and Cassandra’s documentation gives its default value as none, meaning traffic between nodes is unencrypted until it is changed to rack, dc or all. We test the deployment’s actual internode_encryption setting and certificate configuration, not what a default installation ships with once nodes are exchanging data across a real network.
Client-to-Node Encryption
Client-to-node encryption is controlled by the enabled and optional settings in client_encryption_options, and Cassandra’s documentation is explicit that if neither is set to true, client connections are entirely unencrypted, while setting enabled to true with optional also true lets unencrypted connections keep working on the same port. We test which of these states a deployment is actually in, and whether an optional setting is quietly allowing unencrypted client traffic alongside the encrypted connections it was meant to replace.
Network and CIDR-Restricted Role Logins
Cassandra can restrict a role’s logins to specific data centres via network_authorizer or to specific CIDR groups via cidr_authorizer, using CREATE ROLE clauses such as ACCESS TO DATACENTERS and ACCESS FROM CIDRS, but both settings default to their AllowAll implementation, so no role is restricted at all until an operator configures one. We test whether these restrictions are configured for roles that should only ever connect from a known data centre or network, and whether a role with ACCESS FROM ALL CIDRS actually needs that reach.
system_auth Keyspace Replication
The system_auth keyspace, which stores every role, password hash and permission grant, uses SimpleStrategy with a replication factor of 1 by default, and Cassandra’s own setup documentation recommends increasing this to 3 to 5 per data centre with NetworkTopologyStrategy so login remains possible if a node becomes unavailable. We test the deployment’s actual system_auth replication configuration, since a single-replica auth keyspace is also a single node whose compromise or loss affects every credential in the cluster.
JMX Access and Integrated Authentication
Cassandra’s own documentation warns that securing client connections is not enough on its own, since a user able to reach internode communication and JMX ports can still craft internode messages to insert users into the authentication schema, use tools such as sstableloader to overwrite system_auth tables, or attach to the cluster directly to capture write traffic. Cassandra supports standard JMX authentication through a credentials file and integrated JMX authentication and authorisation, where GRANT EXECUTE and GRANT SELECT statements on named MBeans control exactly which nodetool operations a role can run. We test what JMX access is exposed on the network, whether standard or integrated JMX authentication is configured, and whether a role with JMX access could reach system_auth data it should not.
Audit Logging Coverage
Cassandra’s audit logging can capture successful and unsuccessful login attempts alongside QUERY, DML, DDL, DCL and AUTH events once switched on with the nodetool enableauditlog command or the audit_logging_options section of cassandra.yaml, and by default excludes the system, system_schema and system_virtual_schema keyspaces from what it records. We test whether audit logging is enabled at all, and whether its included and excluded keyspace and category filters would actually capture the activity you would want a record of.
OUR PROCESS
Apache Cassandra Security Review: From Scope to Attestation
Scope and Access
We agree which keyspaces, tables and data centres are in scope, plus a role for every privilege tier you want tested and, where possible, read access to cassandra.yaml to confirm authenticator, authorizer and encryption settings.
Configuration and Role Mapping
We map the authenticator, authorizer, network_authorizer and cidr_authorizer settings actually in force, plus every role and permission grant, against who or what actually needs that level of access.
Manual Testing
A CREST-certified tester manually tests the default superuser account, role and keyspace or table permission scope, inter-node and client-to-node encryption, network and CIDR-restricted logins, JMX access and audit logging coverage, 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 Cassandra 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 Apache Cassandra 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 Cassandra 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 Apache Cassandra 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 Cassandra cluster?
We need an authenticated role for every privilege tier in scope, from an ordinary application role through to one that can query role and permission configuration, plus read access to cassandra.yaml or an equivalent configuration export so we can confirm the authenticator, authorizer, network_authorizer and encryption settings actually in force. We can test with role-level access alone if configuration access is not available, though it takes longer to confirm settings indirectly.
Will testing touch live data?
We test the keyspaces and tables you nominate, working against your actual roles, permissions and encryption configuration rather than a copy, so we agree exclusions such as TRUNCATE, DROP or bulk load commands and any production replica before testing starts. We do not export real customer data or run destructive tests without that agreement in writing.
Do you test Cassandra clusters hosted on a cloud provider or run through a Kubernetes operator?
Yes. The authentication, authorisation, encryption and role configuration we test are the same wherever the cluster runs. Where the cluster sits on AWS, Azure or GCP infrastructure, or behind a Kubernetes operator, we confirm the boundary of what you control during scoping and test to that boundary rather than the provider’s underlying infrastructure.
What is out of scope for a single-cluster Cassandra review?
We never test Cassandra’s own source code or JVM internals, the underlying host or hypervisor of a cloud-hosted node, or a cloud provider’s shared infrastructure. A separately hosted application that happens to connect to the cluster is scoped and quoted on its own, and we test the authentication, authorisation, role and permission configuration, network and encryption settings, and audit logging for the cluster you nominate.
Does Apache Cassandra have a policy on customer penetration testing?
Apache Cassandra is open-source software you install and run yourself, whether on your own hardware or a cloud account, so there is no separate SaaS vendor whose permission is needed to test it the way a hosted platform requires. If your cluster runs on a cloud provider’s infrastructure, we confirm that provider’s current penetration testing terms during scoping and test within them.
Is the default superuser account and our role setup covered?
Yes. We check whether the default superuser account is still enabled, whether the replacement superuser Cassandra’s own setup guide recommends creating was ever created, and whether the permissions granted to every other role match what that role actually needs across the ALL KEYSPACES, KEYSPACE and TABLE hierarchy.
How long does an Apache Cassandra security review take?
A single cluster, with a limited number of keyspaces and a small number of distinct roles, sits in our 2-day single-cluster scope, with a report typically landing around 5 working days after kickoff. More keyspaces, multiple data centres, or a mix of self-managed and cloud-hosted nodes moves into a larger scope with more testing days.
Are your testers CREST certified?
Yes. Every Cassandra 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 Apache Cassandra review
Apache Cassandra ships with authentication and authorisation disabled, so a fresh cluster accepts any connection and grants every permission by default. We test authentication, role permissions, network encryption and access restrictions. CREST-certified testers, fixed price from £2,620 for a 2-day single-cluster scope, quoted within 24 hours.
