Magento and Adobe Commerce penetration testing: how the security of an enterprise store is analysed
By Kike Gandia · Co-Founder & CEO, OSCP
A Magento penetration test assesses store security by simulating the behaviour of an attacker who knows the platform: the default paths, the exposed APIs, the common vulnerability patterns in third-party extensions and the business flows that can be manipulated. It's a real offensive analysis, not a version scanner.
Phase 1: Magento-specific reconnaissance
Enumeration in Magento includes: detecting the exact version (Magento 1 vs Magento 2, Open Source vs Adobe Commerce) and its patch level, identifying the admin panel URL (which many stores leave at /admin), enumerating active extensions through fingerprinting of paths and assets, and detecting extension versions via accessible module files.
Testing the admin panel
The Magento admin panel is the highest-value target. Tests include: brute force and credential stuffing (with or without rate-limiting protection), detection of missing MFA, authentication bypass attempts on extensions that modify the login flow, and review of administrator role permissions to identify privilege escalation between roles with limited access.
Analysis of extensions and custom code
Magento extensions are complex PHP modules with full access to the database, the file system and the platform's internal APIs. The analysis covers: matching versions against the history of known CVEs, code review of custom modules looking for SQLi, XSS, SSRF, insecure deserialisation and command injection, and analysis of permission handling on API endpoints registered by extensions.
REST and GraphQL API testing
Magento 2 exposes a complete API (REST and GraphQL) that is the backend of many headless integrations and mobile apps. Tests include: enumeration of unauthenticated endpoints, authorisation testing (access to other customers' resources), mass assignment in resource creation and modification, and injection testing on filtering and search parameters.
Business logic flaws specific to a store
The flaws that cost the most money in Magento are usually not injections but logic errors: the application works exactly as it was programmed, but it was programmed badly. No scanner finds them, because seeing them requires understanding the purchase flow.
What gets tested here: whether coupons can be stacked or reused beyond their limit, whether the total is genuinely recalculated server-side after cart and catalogue rules are applied, whether a negative quantity or an unexpected decimal alters the amount, whether the prices of configurable products and bundles can be tampered with from the request, whether rounding and currency conversion leave an exploitable margin, whether stock is reserved in a way that allows draining inventory without buying, and whether one customer’s orders are reachable by another through a sequential identifier or through the reorder function.
Black box, grey box and code review: what each approach finds
The question that most shapes the outcome is not the tooling, but how much information the testing team is given.
| Approach | What it needs from you | What it does find | What it misses |
|---|---|---|---|
| Black box | Just the URL | Exposed panel, unpatched versions, flaws reachable without an account | Internal logic of custom modules and role permissions |
| Grey box | Test accounts for customers and for each admin role | Escalation between roles, API authorisation flaws, checkout logic | Flaws only visible by reading the code |
| Code review | The repository of the custom modules | Injections, insecure deserialisation, secrets in the repository | Problems in the real environment configuration |
For a store with in-house development, the combination with the best effort-to-findings ratio is grey box against staging plus a code review of the custom modules. Pure black box measures exposure; it does not secure the store.
FAQ
Does Magento penetration testing require access to the source code?
Not for black-box or grey-box analysis. If you want to audit the code of custom extensions, the source code is provided for complementary static analysis.
Can the penetration test be done without affecting real orders?
Yes. Tests that involve creating orders, modifying data or active injections are carried out in a staging environment. If one doesn't exist, we help set it up before the analysis.
What do you need from us to start?
A staging environment equivalent to production, test accounts for customers and one for each admin role that exists, the inventory of installed extensions with their versions, the code of the custom modules if it is to be reviewed, and an agreed window for tests that generate load. With that, the work runs without depending on anyone on your side during execution.
What is delivered at the end?
An executive report for management, a technical report with each finding classified by severity and its reproducible proof of concept, the detail of which extension or which point in the code causes it, and a remediation plan ordered by impact. The closing meeting exists so the development team understands each finding before starting to fix.
Does it affect store performance?
Working against staging does not affect the live store. If part of the scope has to run in production —verifying panel exposure or headers, for example— it is limited to passive or low-impact checks and the window is agreed. Tests that generate load or create orders never run against production without explicit agreement.
If we are still on Magento 1, is auditing it worthwhile?
It can be, but it is worth knowing what you get. Magento 1 no longer receives official patches, so many core findings will have no available fix: the report serves to size the real risk, prioritise mitigations and support the decision to migrate with data instead of intuition. If migration is already decided and dated, auditing the destination usually pays off more than auditing the origin.
Related service
CMS penetration testing service