commercetools Integration Penetration Testing

A commercetools API scope decides which endpoints a token can call, not whether the price, customer or cart behind that call is real. commercetools’ own guidance warns against granting the broadest scope, manage_project, in production, because a client created with it can never be issued a token with lesser scope afterwards.

A scope decides what a token can call, not whether the data behind the call is real

Every request to the commercetools API carries an OAuth 2.0 access token, and that token’s scope is the only thing standing between a compromised client and the rest of the Project. The broadest scope, manage_project, grants every API in the Project except API Clients itself, and commercetools’ own documentation warns it should not be used in production because a client created with it can never be issued a token with lesser scope later. An API Client’s client_id and secret are shown once, at creation, in the Merchant Center, and whichever scopes are ticked at that point are fixed for the client’s lifetime. We check which scope each client in your stack actually carries, whether a storefront, mobile app or custom checkout ships a client_id and secret broader than that service needs, and whether Store-scoped clients are genuinely restricted to the Store they were issued for.

A customer-facing integration typically authenticates with the password flow, exchanging a username and password for a token scoped to that customer’s own ID, or with an anonymous session, which issues a token tied to an anonymousId rather than a signed-in customer. My scopes such as manage_my_profile, manage_my_orders and manage_my_quotes bind every action to whichever customer_id or anonymousId sits inside the caller’s own token, never to a value the request supplies itself; an admin scope such as manage_customers carries no such binding and reaches every customer in the Project. We test whether your integration relies on that binding, or whether it trusts a customerId, cartId or orderId parameter from the client instead, which is what lets one customer read or act on another’s account, cart or order.

A Cart Line Item’s price is normally selected from the Product Variant, but a Line Item or Custom Line Item can be switched to an external price, and a Line Item priced with ExternalTotal has Cart Discounts deactivated even where one would otherwise apply. A checkout service that sets these external prices from a value the client can influence, rather than recalculating them server-side from catalogue data, hands price control to whoever can shape that request. Where a project runs its own logic through an API Extension on Cart or Order changes, or pushes events to a queue through a Subscription, we test whether that destination authenticates the calls it receives and whether the extension can be bypassed, flooded or spoofed to skip the very check it exists to enforce.