Magento 2 security: verifying ACL protection in custom Admin modules

An ACL declaration does not prove access is protected

A custom Magento Admin module usually includes three security pieces: an ACL resource declaration, an Admin controller authorization check, and a menu or route linked to that resource.

These pieces are required. They do not prove that restricted users are blocked from the new functionality.

Teams often test new Admin functionality with a full administrator account. That confirms the page works. It does not confirm that the authorization boundary blocks the right users.

Why new Admin resources need focused testing

A custom module can add backend functionality long after Admin roles were created. Existing roles may already contain permissions or resource relationships that affect access to the new feature.

Access depends on the ACL hierarchy, role configuration, stored authorization rules, and the new resource's place in the tree. Controller code alone may not show how access will work for every role.

Examples of sensitive custom Admin functionality include customer data export, order modification actions, integration configuration, report downloads, API credential management, and operational tooling.

If newly deployed Admin functionality can expose data or change business behavior, include authorization testing in deployment validation.

The administrator-only test creates false confidence

A common test follows this pattern: define acl.xml, add ADMIN_RESOURCE or _isAllowed(), deploy, log in as an administrator, confirm that the page loads, and mark the module secure.

That workflow checks whether the feature works. It does not check whether access is restricted.

A proper security test needs at least three cases: an administrator who should be allowed, a limited role that should be denied, and role-specific verification after deployment when new resources are introduced.

What to verify before deployment

This repository does not include a runnable Magento 2/Adobe Commerce codebase or test environment for controlled ACL reproduction. This article does not claim that every Magento module has the same defect.

Source inspection still shows the runtime enforcement path and its dependency on saved role rules:

Inspect these parts of sensitive Admin access

A hidden menu item does not protect a route. The controller must reject unauthorized direct URL access.

Manual role updates are not a security plan

Manual steps, such as re-saving roles, may fix one access problem. They are a weak long-term process because they depend on someone remembering, running, and checking every affected role.

Use release QA to validate authorization. Define the expected behavior for each sensitive resource, test denied access on purpose, and automate repeatable checks where practical.

If configuration or data migration steps are needed, design and test them against the target Magento version, resource hierarchy, and merchant permission model before using them.

Release checklist for custom Magento Admin modules

Prove that the right Admin users have access

A custom Magento module can contain an ACL file and an authorization check while still allowing the wrong Admin user to reach the functionality.

Code that looks correct is not enough to answer that question.

For every sensitive Admin resource, test the allowed role, test the denied role, test direct URL access, and verify role behavior after deployment. If access control is important enough to build, test it.