Magento 2 security audit: where store protection breaks
A Magento 2 security audit starts not with an automated scanner but with a map of the attacker's entry points. A typical store has four or five of them, and each is either closed by default or remains open for years — because it was forgotten during an update.
A website security check shows that what breaks more often is not the platform core but what was built on top of it.
First — extensions and themes from third-party sources. A module abandoned by its author leaves working paths to files and requests that no one monitors. For an attacker, one such hole is enough to read order tables or upload their own code.
Hence the rule: compare the list of modules with their current state and remove everything that has not been updated or duplicates a native capability.
Second — administrator permissions. When the whole team works under a single account with full access, compromising the panel exposes the catalog, prices, and payment settings. Role separation by area of responsibility and individual accounts limit the damage to one area.
Third — service areas: the panel at a predictable address, test store copies, accessible configuration files, data exchange endpoints without permission checks. Each such address is a ready-made entry point that does not need to be searched for.
Separately — protection against password guessing: without attempt limits and a second factor, logging into the panel becomes a matter of time.
Below we break down how these e-commerce store vulnerabilities are closed — from inventory to server configuration and access rules.
Audit result: which attack vectors are closed
A report with a list of findings is half the work. Value appears when closed vulnerabilities are not reproducible during a re-test: we confirm each finding by re-running the attack scenario against Magento and record the result in the report.
Store administrator permissions
We leave full permissions for one or two accounts, and grant the rest task-based roles: content, orders, reports.
We remove shared "for everyone" logins and accounts of dismissed employees — the volume of unnecessary access decreases, and each administrator's actions are tracked individually.
Protection against password guessing
Login attempt limits, two-step verification for the admin panel, notification of login from a new address. Brute force stops being practical: it hits a lockout rather than connection throughput.
Customer data protection
We encrypt personal data in storage, restrict exports by role and time period, and mask them in logs. Even in a partial incident, the volume of exposed records remains minimal rather than "the entire database."
Closed vulnerabilities in code and extensions
We update third-party modules to supported branches, disable unused ones, and secure form processing and exports with input validation and file permissions.
Typical vectors disappear: code injection through forms, reading other people's orders via a direct address, and access to service files.
We measure the result with three numbers: the share of closed and re-tested findings, response time to a new vulnerability report, and the number of accounts with excessive permissions.
Measurements at the start and at the end show not "it feels calmer" but a reduction in the attack surface.
Assessment formats: one-time, regular, pre-launch
A Magento 2 security audit solves different tasks, so the format is chosen based on the goal, not from the habit of "we scanned once a year." A one-time assessment shows the state on a specific date: open entry points, outdated dependencies, weak access permissions. It will no longer catch what appears after the next release.
Next is the choice between depth and frequency. Below are the formats we apply in practice: what each one closes, when it is appropriate, and what limits it.
Comparison of work formats
| Option | When it fits | Limitations |
|---|---|---|
| Full one-time assessment | First project audit, transition from another contractor, suspected compromise, partner requirement | Snapshot as of a date: changes made after the report are not included |
| Regular scheduled control | A working store with ongoing improvements and connected integrations | Requires an agreed procedure and environment access; a pass between cycles does not replace a full assessment |
| Pre-launch assessment | New project, major redesign, infrastructure or payment environment change | Without real traffic, some logic defects are visible only under load simulation |
| Assessment after major changes | Core update, connecting new modules, payment or customer account change | Limited to the change area — the rest of the environment is assessed based on the previous assessment results |
The formats complement rather than compete with each other: a full assessment sets the baseline, regular control keeps it current, and targeted runs close the risk introduced by specific improvements.
Work order: from inventory to report handover
The work order is the same for a Magento 2 store of any size — only the depth of analysis changes. We start by capturing the current state, because without inventory any finding hangs in the air: it is unclear what exactly produced it and how to check whether it is gone.
-
Inventory of configuration and extensions. We collect the core composition, the list of third-party modules with sources, modifications to base files, and environment settings.
We separately flag unsupported modules and custom modifications — they account for the bulk of findings.
-
Assessment scheme and boundaries. We agree on the environment: test copy, data, work window, what we touch and what we do not. Without this, manual analysis runs into load and access limitations.
-
Manual review of code and logic. We check custom modules, templates, form handlers, and file uploads — automated tools either do not see these places or flag them with false positives.
-
Review of access permissions and integrations. Admin panel roles, integration keys, file and database permissions, payment and warehouse gateways. This is where excess privileges for contractors and old accounts are most often found.
-
Re-test after fixes. We reproduce each fix using the same scenario as the finding and run related paths: a closed vulnerability must not open an adjacent one.
-
Vulnerability report. We rank by criticality; for each one — reproduction condition, cause in the code, and a specific fix, not a generic recommendation.
-
Knowledge transfer to the team. We review the report with your developers, establish secure development rules and a checklist for future releases so that a repeat audit does not start from scratch.
What remains with you: configurations, schemes, procedures
The audit ends not with a report but with a set of artifacts that the team uses to continue independently.
We record all changes in the platform configuration and in the project repository, not in chat — so that when changing a contractor or developer, nothing has to be restored from memory.
- Vulnerability map with priorities. What was closed during the work, what remains, in what order and with what urgency to address it — tied to specific files and settings.
- Security parameters. Environment operating modes, session and cookie policies, file upload restrictions — brought to safe values and recorded in the configuration.
- Access permission scheme. Administrator roles divided into developer, content manager, and analyst; each one has the minimum required set of permissions instead of shared accounts.
- Rules for working with extensions. Where modules may be installed from, what we check before connecting them, how abandoned extensions are decommissioned, and who is responsible for this.
- Integration documentation. Which external services are connected, what data is transferred, where access keys are stored, and how they are rotated according to the procedure.
- Regular assessment procedure. Frequency and scope of assessments, the responsible person, actions when a security update is released — so that protection does not become outdated between audits.
- Incident response procedure. Whom to notify, how to isolate the area, from which backup and in what time we restore.
We write documentation so that your engineer can read it, not just the audit author: short sections, exact file paths, without references to our internal workings.
Case study: a store with an exposed admin panel
A store on Magento 2 with a catalog of about twelve thousand items: order and customer data export went through an extension that had not been updated since the last major platform branch, and the admin panel was exposed from the external network.
Full permissions were held by four contractors and several former employees, no one collected an action log, and backups were stored on the same server. We break down the security audit case: what we found, in what order we closed it, and how the metrics changed.
What the analysis showed
The outdated extension served the order export at a predictable address without permission checks — data could be retrieved without logging into the system.
The admin panel was protected by a single password without a second factor; out of 14 accounts with full permissions, six were unused, and some passwords matched previous environments.
Because no log was collected, the incident was discovered not by an alert but by a customer complaint, and the response time was measured in days.
Closure order and result
We worked from entry points to observability: removed direct access to the admin panel, enabled the second factor, decommissioned the extension, and rewrote the export to use native access permissions.
Then we separated roles according to the principle of least privilege, reducing the number of accounts with full permissions from 14 to 3, and enabled log collection with alerts.
We tested incident recovery on a training copy: copies were moved to a separate environment, deployment was run end to end, and we confirmed that order data and warehouse stock matched.
As a result, incident response time dropped from several days to 15 minutes by alert, recovery time — from 9 hours to 40 minutes, and a repeat audit six months later produced no critical findings.
Vulnerability remediation proceeded in batches with weekly reconciliation: each finding received an owner and a verification date, so the e-commerce store's protection no longer depended on whether someone remembered the old extension.
How does penetration testing differ from configuration review?
Penetration testing answers the question "what is reachable." The engineer walks the external perimeter the same way an attacker would: studies public entry points, tries to bypass authorization, escalate privileges from a regular customer to administrator, and extract other people's order data.
The result is reproducible chains, not a list of abstract risks: each finding is confirmed and shows what it means for the business.
Configuration and code review explains the cause.
It checks not "did it work" but "why did it work": file and directory permissions, admin panel operating mode, session and cookie settings, encryption of service data, request rate limits, content security policies, as well as non-standard modules and themes — most often unclosed places live exactly there.
This is the difference between protection approaches: simulation provides proof of a vulnerability but does not always name which setting opened it; configuration review finds the weak spot but may not notice that it combines with another into a working chain.
Therefore both stages go into one engagement: simulating attacker actions outlines the real perimeter, while configuration, code, and access permission review shows the source of each finding and how to eliminate it.
What the assessment includes: confirmed exploitation scenarios, specific settings and files that allowed them, and remediation priorities — first what gives direct access to data or the admin panel.
Common technical doubts before starting work
Before starting a Magento 2 security audit, clients ask almost the same questions: what access is needed, whether the production store will suffer, and what to do with findings that have been visible for years. Below are short answers that usually eliminate half the back-and-forth.
Is access to the server and database needed?
An external assessment is enough for the perimeter: web server configuration, headers, open ports, and form behavior. But the bulk of findings lives in third-party module code, templates, and file permissions — this is visible only from the inside.
We request read access to the file system and a database copy issued to a separate user with limited permissions; after the work, you revoke the access.
Is the assessment safe on a live site?
We do not run active tests in the production environment: the catalog and checkout must not degrade. Scanning runs in a gentle mode, and everything related to code injection, authorization bypass, and brute force is performed on a copy with anonymized data.
The copy must replicate the production site's configuration; otherwise, some conclusions will be irrelevant.
What to do with findings known for a long time?
We handle them as a separate group: some are closed by updating modules, some by adjusting configuration, and some turn out to be inapplicable due to the architecture. We assign each a priority based on reachability and impact so it is clear what to close first.
Who makes the fixes — you or our team?
We close vulnerabilities ourselves if you do not have your own support team. If the fixes are on your side, we provide a description of the change, the exact place in the code, and a verification scenario that shows the finding is closed.
How often should the assessment be repeated?
The base rhythm is once a quarter, plus unscheduled after major updates, connection of new modules and integrations. We assess stores with active catalog development more often: each extension brings its own code and its own entry points.
Let's discuss the task and come back with an assessment and plan
The assessment of the check relies not on a questionnaire but on the store's actual configuration. The more precise the input data, the fewer assumptions in the assessment and the faster engineers reach real entry points rather than a standard checklist.
What is worth preparing for the conversation:
- The store address and list of environments — production, test, pre-production: we use them to verify where active tests can be run without risk to orders.
- The list of installed extensions and their sources: third-party modules account for the bulk of vulnerabilities, especially those that have not been updated since installation.
- The integration scheme — payment gateways, delivery services, warehouse, external accounting systems: it shows what data leaves the perimeter and where the trust boundary lies.
- The list of administrators and roles: who has access to the control panel, whether there are shared accounts, and how permissions are granted to contractors.
- The history of incidents and requests: suspicious orders, load spikes, customer emails — the most informative traces of real login attempts.
- Environment configuration: PHP branch, web server, caching, file and media placement, session and cookie parameters.
- Update procedure and deployment order: how you apply security fixes, who approves them, and whether there is a fast rollback to the previous release.
This set covers preparation for the assessment almost completely — we will clarify the rest as we go. In response, we come back with a protection work plan: the order of fixes, what we close first, and what can be deferred without increasing risk. Describe the task — we will come back with an assessment and plan.
