ACL (Access Control List) in Shopware

An access control list (ACL) defines who can see and change what in the Shopware Administration. Shopware 6 implements it through roles with individual permissions, which are assigned to users and integrations.

An access control list is a set of rules that determines which action a user or system may perform on a resource: read, create, update or delete. In Shopware 6 this applies to the Administration and the Admin API. Every entity (products, orders, customers, settings) and many functions (cancelling orders, installing plugins, clearing the cache) have their own permissions.

The principle behind it is least privilege: everyone gets only the rights they need for their work. A customer service agent may view orders and change their status but not adjust prices; an ERP connector may write stock levels but not create users.

Shopware 6 works with roles, which you create under Settings → System → Users & permissions. A role bundles permissions, grouped by area such as catalogues, orders, customers, content, marketing, settings and extensions. For each entity you choose read, create, update and delete separately; there are also rights for individual actions, such as generating documents or changing the payment status.

Users are given one or more roles, and the rights add up. Administrators with the “Admin” flag bypass the check entirely. The same roles apply to Admin API integrations: when you create API access under Integrations, you assign it a role, and the API rejects calls without the matching right with a 403.

Technically, Shopware checks permissions in two places: in the Administration, where menu items, buttons and fields without permission are hidden, and in the backend, where the Data Abstraction Layer checks every read and write access against the permissions of the context. The interface is a convenience; the backend check is the actual security.

• Customer service: read and edit orders and customers, change statuses, generate documents; no access to prices, settings or extensions.
• Content and marketing: edit Shopping Experiences, categories, media and promotions; orders read-only.
• Product data: full rights on products, properties, manufacturers and media; no orders.
• Accounts: read orders and documents, change payment status; nothing else.
• ERP or PIM integration: exactly the entities the system writes (products, stock, order status), without user, settings or plugin rights.
• Agency or developer: time-limited access with rights for extensions, themes and settings, revoked once the project is finished.

Custom plugins bring their own permissions: new entities appear automatically in role management, and the plugin registers additional rights for its own admin modules via a privilege definition (Shopware.Service("privileges").addPrivilegeMappingEntry) in the Administration code. This lets you tie your own functions, such as an export button, cleanly to roles. Apps declare their permissions in the manifest.xml; missing rights cause the app’s webhooks or API calls to fail. Read how we build extensions with clean permissions on our Shopware plugin development page.

• Design roles around tasks, not people. Staff change, tasks remain.
• Use the Admin flag sparingly: admins bypass every check. Two or three people are enough.
• One integration per system: ERP, PIM and middleware each get their own credentials with their own role, so you can revoke one access without affecting the others.
• Review rights regularly: go through who has which role every quarter and remove leavers and completed agency projects.
• Enable two-factor authentication for all users with write access.
• Traceability: document changes to roles and users; for sensitive data, check access via the logs. Under UK GDPR, limiting and documenting access to customer data is part of appropriate technical and organisational measures.

• Everyone is an admin: the most common case in small teams. A compromised account then has full access.
• Missing read rights on dependencies: anyone who edits orders also needs read rights on customers, payment and shipping methods, otherwise fields stay empty or saving fails.
• Integration with an admin role: API access with full rights is a security risk, especially when the key sits in middleware.
• Rights not extended after plugin updates: new entities or modules require new permissions in existing roles.

User management, Admin panel, OAuth, Access token and Context token. For an overview of all terms, see our Shopware Dictionary.