ShopWired Store Security Review

ShopWired limits each account to 10 webhooks per topic, whether created through the admin system or by an OAuth app. We test which webhooks are actually registered against what your team believes is configured, and what happens once that limit is reached.

Why ShopWired findings sit in your app’s scopes and webhooks, not the store

ShopWired’s API supports two authentication methods: HTTP Basic Authentication using an account’s API key and secret, and OAuth2 for third-party apps, which are issued a Client ID, Client Secret and a separate Signature Secret. An OAuth app requests a comma-separated list of permission scopes in its authorisation URL, and the merchant approves or denies them at install. We test which scopes an app was actually granted against what its API calls use, and how the API key and secret pair, or the OAuth client’s credentials, are stored by the integration holding them.

A ShopWired webhook must be reachable over HTTPS, is verified with a signed challenge when first created, and every subsequent request carries a signature in the X-ShopWired-Signature header, generated from either the account’s secret or the OAuth client’s signature secret depending on who created it. A handler has 5 seconds to return a 200 status or ShopWired will retry for up to 24 hours before disabling the webhook. We test whether the receiving endpoint actually verifies that signature, and whether a retried call can be processed more than once.

The API is rate limited using a leaky bucket of 40 requests with a leak rate of 2 requests per second, reported to the client through the x-rate-limit-remaining response header, and access to each endpoint is gated by its own read or write permission rather than one blanket scope. We test whether an integration’s retry and backoff logic handles a 429 response safely, and whether the permissions an app holds still match every endpoint it calls.