Redis Security Review
Redis’s default user has no password and no limits on commands or keys, until authentication is switched on. We test bind address, ACL users, TLS and the admin commands left enabled. CREST-certified testers, fixed price from £2,620 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.”
Redis’s own ACL LIST output shows the default user as user default on nopass ~* &* +@all: active, no password required, every key and every command. That is not a misconfiguration, it is how a fresh Redis 6 or later install behaves until you change it.
Why Redis security comes down to authentication, network exposure and which commands are still enabled
Redis’s own ACL documentation shows the default user’s ACL LIST line as user default on nopass ~* &* +@all: active, no password required, every key and every command available, and confirms that is how Redis 6 and later behave until that user is changed, kept for backward compatibility with older clients. A user created afterwards through ACL SETUSER starts from the opposite position, off with no key patterns and no commands until rules are added, so the gap between a new account and the default user is the first thing we map. The older alternative, requirepass, sets one shared password used by every client, and Redis’s security documentation is direct that the AUTH command carrying it is sent unencrypted, so it does not protect against an attacker able to eavesdrop on the network.
Redis’s reference configuration ships with bind 127.0.0.1 -::1 and protected-mode yes, so a server built from that file only accepts loopback connections, and the same security documentation explains that protected mode exists for the moment the bind line is widened without a password also being set, replying only to loopback clients until an administrator disables it manually. Encryption is opt-in in the same way: Redis’s TLS documentation states TLS became available in Redis 6 as a feature that must be compiled into the binary, and that where it is enabled Redis defaults to mutual TLS, requiring a valid client certificate as well as a server one, unless tls-auth-clients no is set.
CONFIG, DEBUG and MODULE LOAD each carry the @admin and @dangerous categories in Redis’s own command reference, and current versions ship enable-protected-configs, enable-debug-command and enable-module-command settings that default to blocking each of them for every connection until an operator turns them on. rename-command, Redis’s older way of hiding a command such as CONFIG behind an unguessable name, is documented as deprecated now that ACL rules can disallow commands directly. Managed Redis moves some of this into a console instead of a config file: AWS’s customer penetration-testing policy does not currently list ElastiCache among the services approved for testing without prior approval, and we have not found an equivalent published policy for Redis Cloud, so we confirm each vendor’s current terms during scoping. For the wider family this scope splits from, see our NoSQL, cache and streaming security review, and our MongoDB security review for the document-store side of that split.
SCOPE
What we review in a Redis deployment
Network Exposure: Bind Address and Protected Mode
Redis’s reference configuration ships with bind 127.0.0.1 -::1 and protected-mode yes, so an instance built from that file only accepts loopback connections. Protected mode exists for the moment that changes: Redis’s own security documentation states it replies only to loopback clients whenever Redis is bound to every interface without a password configured, and that an administrator can still disable it manually. We test what the deployment’s actual bind address, firewall rules and protected-mode setting allow once it has been opened to an application server or a wider network.
Authentication: requirepass, ACL Users and the Default User
Redis’s ACL LIST reports the default user as on nopass ~* &* +@all: active, no password required, every key and every command available, which is how Redis 6 and later behave until that user is changed. The older requirepass setting sets one shared password used by every client, sent as plain text over the wire unless TLS is enabled. We test whether the default user has actually been restricted, and whether requirepass or an ACL password can resist the request rate a fast in-memory store can sustain.
ACLs: Command Categories and Key Pattern Permissions
ACL rules combine command categories, such as +@read or -@dangerous, with key patterns such as ~app:*, and Redis’s own documentation confirms a user created through ACL SETUSER starts as off with no commands and no key patterns until rules are added, the opposite of the default user. We test every user’s actual categories and key patterns against what that application or person needs, not the broad access it may have been given when the account was first set up.
Dangerous Administrative Commands: CONFIG, MODULE LOAD and EVAL
CONFIG, DEBUG and MODULE LOAD are tagged admin and dangerous in Redis’s own command reference, and current versions ship enable-protected-configs, enable-debug-command and enable-module-command settings that default to blocking each of them for every connection until an operator turns them on. EVAL runs Lua scripts under the same protocol rules as any other command, and Redis’s own documentation cautions against composing a script’s body from strings obtained from untrusted sources. We test which of these commands are reachable, by whom, and whether the hardened defaults have been left in place or switched off.
Command Renaming and Disabling: FLUSHALL, DEBUG and rename-command
FLUSHALL carries the dangerous category, and Redis’s own security documentation gives it as the standalone example of what an external attacker can do to an exposed instance: delete the whole data set in one call. rename-command is Redis’s older way to hide a command such as CONFIG behind an unguessable name or an empty string, documented as deprecated now that ACL rules can disallow commands directly. We test whether FLUSHALL, DEBUG and other high-impact commands are reachable by every authenticated client, and whether a rename-command entry is actually enforced or just present in a config file nobody reloaded.
Transport Encryption (TLS)
TLS became available in Redis 6 as a feature that must be compiled into the binary, so it is not guaranteed to be present just because a deployment’s version number supports it. Where it is enabled, Redis defaults to mutual TLS, requiring a valid client certificate as well as a server one unless tls-auth-clients no is set, and separate tls-replication and tls-cluster directives extend encryption to replica links and the cluster bus. We test whether TLS is actually compiled in and enforced on every port and link in scope, not only the client-facing one.
Tenant Separation When Multiple Applications Share One Instance
A key prefix such as app1:* is a naming convention, not a permission boundary, unless it is enforced through an ACL key pattern tied to a user that only that application authenticates as. We test whether every application or team sharing an instance actually authenticates as its own ACL user scoped to its own key pattern, or whether they all connect as the same account and rely on prefixes that any of them could bypass with an unrestricted command.
Sensitive Data Cached: Sessions, Tokens and PII
Redis holds whatever an application writes to it, so session tokens, password reset codes and cached personal data carry the same exposure in Redis as anywhere else once an unauthorised client can run a read or scan command against the keyspace. We test what your application actually stores, whether values are readable in plain text, and whether an account with broad key-pattern access can read data that belongs to a different user or tenant.
Persistence Files (RDB/AOF) and Replication
RDB snapshots and AOF logs write the dataset to disk in full, and Redis’s own documentation suggests copying an RDB file to storage such as Amazon S3 possibly encrypted as a separate step, so encryption at rest is not automatic. Replicas are read-only by default since Redis 2.6, but Redis’s own replication documentation is explicit that this does not make a replica safe to expose, since administrative commands such as DEBUG and CONFIG remain enabled on it. We test who can read the RDB or AOF file on disk, and whether a replica or a masterauth password is treated with the same care as the primary instance.
Managed Redis: ElastiCache, Azure Cache and Redis Cloud
AWS’s customer penetration-testing policy does not currently list ElastiCache among the services approved for testing without prior approval, so we confirm AWS’s current terms and request approval where needed before scoping an ElastiCache engagement. Microsoft’s Azure policy permits testing any Azure service you own without pre-approval provided testing stays within the published rules of engagement, and we have not found a published customer penetration-testing policy for Redis Cloud in the way AWS and Azure publish for their platforms. We test the application, ACL configuration and network access around whichever managed service you use, to the boundary its shared-responsibility model actually gives you.
OUR PROCESS
Redis Security Review: From Scope to Attestation
Scope and Access
We agree which Redis instances, replicas and managed deployments are in scope, plus an ACL user for every privilege tier you want tested and, where relevant, console access to ElastiCache, Azure Cache or Redis Cloud.
Configuration and ACL Review
We review bind addresses, protected mode, TLS settings and every ACL user’s command categories and key patterns against who or what actually needs that access.
Manual Testing
A CREST-certified tester manually tests authentication, network exposure, dangerous and renamed commands, tenant separation between applications sharing an instance, and what persistence files and replicas expose.
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 Redis 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 Redis 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 Redis 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 Redis 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 Redis deployment?
We need at least one authenticated account for every privilege tier in scope, from an ordinary application user through to an ACL user that can read configuration and other users’ permissions. On managed services we also ask for read access to the console so we can check network, access-list and encryption settings alongside what the instance itself reports.
Will testing touch live data?
We test the instances, key patterns and applications you nominate, working against your actual configuration and data rather than a copy, so we agree exclusions such as FLUSHALL, FLUSHDB or destructive scripting before testing starts. We do not export real customer data or run destructive commands without that agreement in writing.
Do you test self-managed Redis and managed services such as ElastiCache the same way?
The underlying questions are the same: who can authenticate, what they can run, and what the network exposes. What differs is the boundary, since a managed service controls the host, patching and some configuration directives, so we confirm during scoping exactly what you control on your tier and test to that boundary.
What is out of scope for a single-system Redis review?
We never test Redis’s own source code, the underlying host or hypervisor of a managed instance, or the cloud provider’s shared infrastructure, and a separately hosted application that happens to connect to Redis is scoped and quoted on its own. We test the authentication, ACLs, network configuration, persistence and application-level use of the instance you nominate.
Does AWS, Microsoft or Redis have a policy on customer penetration testing?
AWS’s published permitted-services list for testing without prior approval does not currently include ElastiCache, so we confirm AWS’s current terms and request approval during scoping where needed. Microsoft’s Azure policy allows testing any Azure service you own without pre-approval, and we have not found an equivalent published policy for Redis Cloud, so we confirm Redis Ltd’s current terms for that platform too.
How long does a Redis security review take?
A single Redis instance or managed cluster, with a limited number of ACL users and applications connecting to it, sits in our 2-day single-system scope, with a report typically landing around 5 working days after kickoff. Multiple instances, a mix of self-managed and managed deployments, or several applications sharing one instance moves into a larger scope with more testing days.
Is Valkey tested the same way as Redis?
Valkey is an open source fork backed by the Linux Foundation that includes BSD-licensed Redis code and describes itself as compatible with legacy Redis OSS, so the same authentication, ACL and configuration questions apply. We confirm which engine and version is actually deployed during scoping and test to that version’s real command set and defaults, rather than assuming it matches Redis.
Are your testers CREST certified?
Yes. Every Redis 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 Redis review
Redis’s default user has no password and no limits on commands or keys, until authentication is switched on. We test bind address, ACL users, TLS and the admin commands left enabled. CREST-certified testers, fixed price from £2,620 for a 2-day single-system scope, quoted within 24 hours.
