AEM Penetration Testing
Adobe Experience Manager (AEM) separates Author from Publish, and Dispatcher decides what the public side can actually reach. We test your Dispatcher rules, repository permissions and the endpoints your custom code exposes. CREST-certified testers, fixed price from £3,380 for a 3-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.”
Publish is the tier the public can actually reach, and Adobe’s own architecture confirms it is the only tier fronted by Dispatcher. What Dispatcher lets through, and what your repository permissions allow once a request lands, is what we test.
Why AEM security depends on Dispatcher rules and repository permissions
Adobe Experience Manager splits authoring from delivery into separate tiers, and only one of them is internet-facing. Author holds the content repository your editors work in; Publish is what the public actually requests, sitting behind an Apache instance running Dispatcher, the module Adobe’s own security checklist treats as the first line of defence. We test what that Dispatcher configuration actually lets through, not the tier nobody outside your organisation can reach.
Dispatcher’s job is to decide which paths, selectors and extensions reach Publish at all, and the ones worth checking are the ones a default configuration leaves open: the query builder’s JSON servlet, the automatic .json rendering that walks the content tree beneath any resource, the OSGi web console, and CRXDE Lite if its bundle was never removed before going live. None of these bypass your repository’s access control, they return exactly what the requesting account is allowed to read, which is precisely why the permissions behind them matter as much as the filter rules in front.
Behind Dispatcher sits the repository’s own permission model: access control entries evaluated per node, where a user’s own entry always overrides a group entry and membership of one group inside another has to be granted explicitly rather than inherited automatically. Your custom Sling servlets, selectors and HTL components sit on top of both layers, and a component that reads more of the repository than the page in front of it needs, or a script value rendered without its escaping context declared, can undo what the Dispatcher and ACL configuration got right. We test your configuration and your code, not the AEM platform underneath either.
SCOPE
What we pen test on an AEM instance
Author and Publish Separation
AEM Author holds the single content repository your editors work in and, on AEM as a Cloud Service, carries no Dispatcher at all, Adobe’s own documentation confirms Dispatcher configuration is simply ignored there. Every Publish instance is paired with its own Apache and Dispatcher module instead, the layer that actually fronts the CDN. We test what that split lets through to Publish, the same author-and-delivery boundary we test on Sitecore’s CM and CD tiers.
Dispatcher Filter Rules
Dispatcher’s own security checklist recommends allowlists over blocklists, since a blocklist only stops what someone remembered to add. We test your filter configuration against that logic: whether /etc and /libs are blocked by default with only the specific subpaths your front end needs opened back up, and whether an administrative path can still be reached because a rule was written too broadly or in the wrong order.
Dispatcher Caching and Cache Abuse
Dispatcher caches whatever variation of a URL returns a cacheable response, and Adobe’s own guidance on preventing denial of service warns that the same handle can be requested with extra selectors, extensions or suffixes to generate near-unlimited cache entries. We test whether your caching rules are scoped to the mime types and paths you actually serve, and whether restricting which clients can flush the cache is enforced.
Query Builder and JSON Renderings
The QueryBuilder REST endpoint at /bin/querybuilder.json is documented by Adobe as a way to query the repository over HTTP, and the default .json rendering on any resource can walk the tree beneath it up to the json.maximumresults limit, 1,000 by default. We test what an anonymous or low-privileged Publish request can enumerate through both, since either one only ever returns what the requesting account is actually allowed to read, and that is precisely the boundary we are checking.
/system/console and Default Admin Passwords
The OSGi web console gives administrator access to AEM’s configuration once you can reach it, and Adobe’s own security checklist requires this path to be blocked from external access at the Dispatcher and treats the console’s admin account and the AEM admin account as two separate passwords that must both be changed from their default value after installation. We test whether the console is genuinely unreachable from Publish, and whether either credential was left on a default or shared value.
CRXDE and Development Bundles
CRXDE Lite gives direct read and write access to the JCR repository through a browser, and Adobe’s security checklist calls for the CRXDE Lite, CRXDE Support and CRX Explorer bundles to be uninstalled from both Author and Publish before either goes into production. We check whether any of the three are still installed and reachable, and whether the same applies to the Sling Tooling Support bundle that AEM’s developer tools deploy.
Repository ACLs and Group Precedence
AEM’s access control is evaluated per node: a user’s own ACL entry always overrides a group entry regardless of where either sits in the hierarchy, and Adobe’s documentation is clear that adding one group as a member of another does not automatically hand over that group’s permissions. We test the effective permissions on the paths that matter, comparing what an account can actually do against its group membership rather than assuming the two match.
Custom Sling Servlets and Selectors
Every selector, extension and suffix your application defines is a request Sling will try to resolve, and Adobe’s own guidance recommends serving only the exact selectors an application needs and returning 404 for everything else, since the default form-chooser and asset-download servlets have both been documented causing denial of service when left open to unrestricted, repeated requests. We test the custom servlets and selectors your own code registers, not the Sling framework underneath them.
Custom Components and HTL Output
HTL escapes output automatically based on where it sits in the markup, but Adobe’s own documentation is explicit that it cannot parse inline JavaScript or CSS, so a value placed inside a script or style block needs its context declared, or HTL removes the output rather than risk it. We test your custom components for exactly that gap, values that reach a script or style context without an explicit context set, and component logic that reads more of the repository than the page it renders needs.
AEM as a Cloud Service vs On-Premise or AMS
On AEM as a Cloud Service, reaching an environment at all depends on an Adobe Admin Console product profile before AEM’s own local groups and ACLs decide what that account can do, Adobe’s own documentation is explicit that the two layers are independent and neither one is enough on its own. On-premise and Adobe Managed Services deployments skip the product profile layer entirely, so repository ACLs and Dispatcher configuration on both Author and Publish carry the whole access-control burden. We test whichever model your instance actually runs.
OUR PROCESS
Adobe Experience Manager Penetration Testing: From Scope to Attestation
Scope and Access
We agree the Author, Publish and Dispatcher environments in scope, the accounts we need for each repository group, and whether custom Sling servlets, components or Experience Cloud integrations are included.
Dispatcher and Permission Mapping
We map your Dispatcher filter and caching rules against Adobe’s own security checklist, then map the repository’s user and group ACLs and every custom servlet or selector your code registers.
Manual Testing
A CREST-certified tester manually tests what Dispatcher actually lets through to Publish, the query builder, JSON renderer, OSGi console and CRXDE among them, plus repository permission boundaries and custom component logic, 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 AEM 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 Adobe Experience Manager Penetration Testing Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
3 to 4 testing days
Single user role, basic CRUD application, marketing website with auth. Around 5 working days from kickoff to report.
Get a fixed quote4 to 6 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote6 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 AEM 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 Adobe Experience Manager Penetration Testing
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 AEM instance?
At least one Author account for the tier you author on, and, where possible, a Publish account for each anonymous or authenticated group you actually run in production. Read access to your Dispatcher configuration, the filter and cache sections in particular, speeds up coverage but is not required for black-box testing.
Will testing touch our live data?
We test whichever environment you give us, and where that is production we agree exclusions in advance, such as bulk publish or delete actions, replication to live agents, and any workflow that sends real email or payment traffic. Read-only checks against production content are logged as they happen.
How long does an AEM penetration test take?
A single-instance AEM engagement sits in our 3-day scope, with a report typically landing around 5 working days after kickoff. More Author or Publish environments, a larger set of custom components, or additional Experience Cloud integrations in scope move into a larger engagement with more testing days.
Do you test AEM as a Cloud Service and on-premise or AMS the same way?
The testing goals are the same, what Publish can actually expose and whether your repository permissions are correct, but the detail changes. On AEM as a Cloud Service we test the Adobe Admin Console product profile and local-group model together, and Author itself has no Dispatcher to test since Adobe’s own documentation confirms that layer only sits in front of Publish. On-premise or AMS, we test Dispatcher configuration on both Author and Publish, since neither is Adobe-managed there.
What is out of scope for a single-instance AEM test?
The underlying AEM platform code, the parts of Cloud Service Adobe operates directly such as the container orchestration and CDN infrastructure, and any separate Adobe Experience Cloud product beyond the AEM instance itself, unless you scope that integration in as well. A network or infrastructure review of self-hosted or AMS servers is a separate cloud or infrastructure engagement.
Do you need our source code?
No. Testing is black-box against the running Author and Publish tiers by default. A grey-box option, where we review your Dispatcher configuration, custom Sling servlets and HTL components alongside testing, is available if you want faster or deeper coverage of specific findings.
Does Adobe have a penetration-testing policy we need to follow?
Yes, for AEM as a Cloud Service. Adobe’s current documentation requires every planned test to be scheduled and disclosed in advance through Experience Hub, under Admin & IT > Security and Compliance > Penetration Tests, including the dates, domains and IP addresses in scope, the assessor, and confirmation that the test does not include a DDoS attack. We confirm your instance’s current terms with you during scoping before any testing starts, since an on-premise or AMS deployment does not carry the same self-service process.
Is the Dispatcher configuration included in testing?
Yes, where you can give us access to the configuration files or a working Dispatcher in front of Publish. Without it we test what Dispatcher actually allows through from the outside, which is usually the more realistic test, but reviewing the configuration directly finds rule mistakes that black-box testing alone might not trigger during a fixed testing window.
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 AEM instance
Adobe Experience Manager (AEM) separates Author from Publish, and Dispatcher decides what the public side can actually reach. We test your Dispatcher rules, repository permissions and the endpoints your custom code exposes. CREST-certified testers, fixed price from £3,380 for a 3-day single-instance scope, quoted within 24 hours.
