Shopware Penetration Testing

Shopware runs a customer-facing Store API and a separately credentialed Admin API side by side, and each one carries its own keys, tokens and blast radius.

Why a Shopware engagement covers two separate APIs, not one

Shopware runs two separate HTTP APIs rather than one. The Store API is the customer-facing surface for product browsing, cart handling, checkout and account management, and it supports both anonymous shoppers and authenticated customers from the same endpoints. Every request against it carries a sw-access-key tied to one sales channel, copied from that channel’s API access settings, and generating a new key invalidates the old one immediately. The Admin API sits behind a separate OAuth layer entirely: an Integration created under Settings, System, Integrations issues an access key ID and secret access key that map to an OAuth client_id and client_secret, used with the client_credentials grant to obtain a bearer token for backend, order and customer management calls. We test both surfaces as what they are: two independently credentialed systems where a breach on one side should not automatically open the other.

Extending a Shopware store today can mean building an app rather than a classic plugin, and an app only gets as much reach as its manifest.xml declares. Permissions combine a privilege, read, create, update or delete, with an entity, or use the crud shortcut to request all four at once, and Shopware describes this whole mechanism as creating a fine-grained Access Control List entry for that app. Installing an app triggers a signed registration handshake: a request carrying the shop’s ID, URL and a timestamp, signed with an app-secret in the shopware-app-signature header, and any later re-registration or secret rotation must be validated against both the new and the previous shop-secret. We test whether an app’s own code enforces the scope it declared, and whether its endpoint actually checks both signatures during a rotation rather than trusting whichever one arrives first.

Flow Builder lets a shop owner chain a business event to one or more automated actions without writing code, which means a change to a single flow can alter order status, customer data or outbound webhooks across the whole store without a deployment. Checkout itself runs through the same Store API used for browsing, so address selection, promotions and order placement for both guest and logged-in customers sit on one continuous surface. Where a store is self-hosted, that surface extends to the server and database underneath it; where it runs on Shopware’s cloud offering, that infrastructure layer is out of your reach and testing concentrates on apps, integrations, automations and the code you have added around them. We agree which of these applies during scoping rather than assuming one.