A useful Shopify app pentest asks whether someone can cross a store boundary, misuse a privileged workflow or turn access to the app into access to its infrastructure. A generic scan of the login page cannot answer those questions.
Shopify app penetration testing combines web and API testing with the app’s installation lifecycle, merchant permissions, asynchronous jobs and hosting architecture. It should produce reproducible findings and a clear statement of what was tested. This guide explains how to scope that work, what the test cases should cover and how to judge the report.
Choose the right engagement. A pentest validates attack paths. A Shopify app security audit also examines configuration, development processes and operating evidence. For the architecture and preventive controls behind both, read our Shopify app security guide.
Define the systems the tester is allowed to assess
Write the scope around assets and ownership. Include your app backend, API routes, merchant interface, storefront components, authorized cloud resources and relevant supporting tools. List the account IDs, hostnames and environments. Separate the app you operate from Shopify’s own infrastructure and other vendors’ services.
Permission to test your app does not grant permission to attack unrelated stores or the underlying Shopify platform. Use stores and accounts your organization controls, obtain any additional approvals required for the agreed environment, and identify stop conditions for unexpected access to real customer data. Define allowed techniques, test windows, request budgets and an emergency contact in the rules of engagement.
Start with an inventory of routes and jobs, then classify each one by authentication method, data sensitivity and business effect. Include REST or GraphQL endpoints exposed by your own app, webhook receivers, app-proxy routes, uploads, exports and support interfaces. Features that are not visible in the main navigation may still accept requests.
Separate three scopes that buyers often combine accidentally: the merchant’s store configuration, the app vendor’s software, and the vendor’s cloud infrastructure. One engagement can cover all three when authorized and priced accordingly. A report should not imply that a test of one store proves the security of a vendor’s entire multi-tenant service.
Use authenticated and source-assisted testing where it matters
Unauthenticated testing shows what an outside caller can reach. Authenticated testing adds the behavior of merchants, customers and staff. Source-assisted testing helps trace tenant context, token selection and queued work through paths that a browser alone may not reveal. These approaches complement one another; choose coverage based on the application rather than a label on a quotation.
Prepare at least two authorized test stores with separate sample records. Add accounts representing the roles your app actually supports. Record expected permissions before testing so that a disputed result can be compared with an agreed policy. If merchant staff permissions are relevant, establish whether the app uses them directly or implements its own role model.
A sound methodology can draw on OWASP WSTG v4.2, applicable ASVS 5.0.0 requirements and the OWASP API Security Top 10. Ask the tester to identify versions and coverage. “OWASP tested” is not a complete description of an engagement.
Prove tenant isolation with controlled data
For each important object, define who owns it and which actors may read, change, export or delete it. Then test both permitted and forbidden combinations using deliberately created fixtures. The expected result for a denied request includes its downstream effects: no background job, file, cache entry or notification should reveal another store’s data.
The test should cover different identifier locations and processing paths without assuming that one successful check proves the rest. A safe order endpoint does not establish that a bulk export, file download or search resolver applies the same policy. Conversely, an opaque identifier is not itself proof of authorization. OWASP describes the underlying failure class as broken object-level authorization.
Ask the tester to inspect background-worker context where source access is available. Does the job retain a verified tenant identity? Can a retry resolve a record against a different installation? Are exported files segregated, and does the download handler verify the requester rather than simply knowing a storage path? These questions frequently expose differences between the app’s web layer and its operational machinery.
Test installation, sessions and loss of access
The test plan should follow the app lifecycle. Installing, reinstalling, changing scopes and uninstalling can leave different states in the app database, token store and job queue. Verify that a stale session or queued task cannot restore access that has been revoked.
For the embedded interface, test validation of Shopify-issued ID tokens, including invalid signatures, expiry and claims that do not match the intended app or store. For an OAuth authorization flow, review state binding and redirect handling. Use the current Shopify authentication guidance to choose the correct mechanism for each route; webhook authentication is not interchangeable with browser-session authentication.
Where the app uses online access tokens, examine the relationship between the token and staff permissions. Where background work uses offline access, inspect how the application independently limits a human user’s ability to trigger that work. A broadly capable service token should not automatically turn a low-privilege user into an administrator.
Include refresh and recovery behavior in the test fixtures. The aim is to detect unintended access and inconsistent state, not to disrupt a merchant’s live installation. Any revocation exercise on production credentials needs its own agreed plan.
Test webhooks, app proxies and business logic
Use a test matrix with expected outcomes, not a single “webhooks passed” line. A valid event should produce the intended effect once. An invalid event should produce no trusted state change. A duplicate or out-of-order event should follow the application’s documented rules without granting a second credit, duplicating fulfillment or undoing a newer state.
Shopify’s HTTPS webhook verification uses the raw request body and requires duplicate handling. Test the middleware and queue integration as deployed, including what happens when verification fails. Do not assume the development harness uses the same processing path as production.
App-proxy verification establishes a signed request context; it does not make every visitor a merchant administrator. Verify what anonymous visitors and authenticated customers may do on those routes. A public configuration lookup and a write to store-wide settings require very different permissions.
Business-logic testing should reflect what the app sells. For a returns app, that may include who can approve a return and whether an approval can be reused. For a loyalty app, it may involve the consistency of credit adjustments. For an export app, it may involve access to completed files and cancellation. Use synthetic orders and agreed financial limits; record why each scenario is relevant to the actual product.
For your own GraphQL API, review authorization at resolver and object-property level, not just at the top-level request. Examine query cost and repeated expensive operations under controlled limits. Shopify’s API limits do not automatically protect your application’s own database or export workers.
Cover browser, upload and server-side processing paths
Test where untrusted values become HTML, URLs, template output, CSV content or administrative displays. Stored content may reach merchants, shoppers and support staff through different renderers. A finding in a privileged support console can have a different impact from the same input in an isolated preview.
Embedded interfaces also require careful cross-frame messaging. Review origin and source validation, allowed message types and whether a message can trigger a sensitive action. Shopify provides specific guidance on cross-frame message validation. A permissive browser message handler should not become a parallel authorization channel.
For image imports, callback configuration and URL-based integrations, review outbound requests. The assessment should determine whether a controlled input can reach destinations the application should never access. Use safe endpoints operated for the test and examine egress controls and workload permissions. OWASP’s SSRF guidance explains why a service fetching a URL can create a path across network boundaries.
Uploads need their own review: type handling, parser behavior, storage permissions and the origin used to serve the result. The tester should explain whether the evidence demonstrates a harmless validation gap, a data exposure or a path to code execution. Those are materially different findings.
Include hosting and WAF behavior explicitly
A web-only scope can miss a public database, an overpowered workload identity or a deployment account that can replace application code. Decide whether the engagement includes a cloud configuration review, external infrastructure testing, or both. Record any inaccessible management plane as a limitation instead of treating it as assessed.
Assess the normal public route with the WAF enabled to understand the protection merchants actually receive. If deeper application testing is authorized, use a separately agreed staging path or a narrowly controlled testing exception. Report these conditions separately. Disabling protection globally obscures real-world behavior; allowing the WAF to block every test leaves the application’s underlying behavior unresolved.
Verify that the intended origin restrictions work. Cloudflare’s Authenticated Origin Pulls documents one origin-authentication mechanism. The correct solution depends on the hosting model; a vendor’s default hostname, alternate load balancer or old deployment can represent a separate path that also needs review.
Request bounded checks of rate controls and expensive operations. Capacity testing and denial-of-service exercises should be separately agreed. A pentest can identify missing constraints without exhausting the production service.
What a useful Shopify app pentest report contains
Require a scope statement naming the release, environments, authorized stores, roles, interfaces, dates and exclusions. The report should distinguish confirmed behavior from hypotheses and list important areas that could not be tested. A clean-looking executive page with no coverage record is weak evidence for a merchant or buyer.
For each confirmed issue, expect the affected component, preconditions, controlled reproduction, redacted evidence, business impact, recommended fix and retest result. Severity should reflect tenant reach, privileges needed and exposure of the affected data. Avoid treating every missing header as equivalent to a cross-store data access flaw.
Illustrative finding: export ownership is not checked
Evidence: an authorized Store A test account retrieved a synthetic export created for Store B. The finding records the relevant release, request, response and file identifier.
Fix: enforce ownership at the download handler and preserve verified tenant context in the export worker. Add negative tests for both paths.
Retest: Store A is denied Store B’s file, Store B can still retrieve its own file, and no replacement link leaks through a retry. This is a worked example, not a claim about a real client.
Close the engagement by agreeing owners and priorities. Retest affected paths after remediation and report any coverage limits in the retest itself. A patch to the first endpoint is insufficient if another route still reaches the same object without authorization.
Prepare a scope that can be priced accurately
Provide the app distribution model, architecture, number of distinct workflows, APIs, roles, test stores, hosting accounts and relevant integrations. Describe sensitive actions such as publishing storefront content, managing subscriptions, exporting data or issuing credits. State whether source access, cloud configuration and retesting are required. Page count alone is a poor proxy for testing effort.
Use our pentest RFP builder to send the scope, or review API penetration testing and cloud penetration testing for the components you need covered. App testing and a merchant-wide ecommerce audit are different engagements; the proposal should identify which one you are buying.
Shopify app pentesting questions
Is a vulnerability scan enough?
No. Scanners help identify known patterns and exposed components. Tenant isolation, multi-step business rules and asynchronous behavior need targeted verification with realistic roles and fixtures.
Does a pentest include source code?
Only if agreed. Source-assisted testing can improve coverage of token handling, queues and shared authorization logic. The report should state which repositories and release were reviewed.
How often should an app be retested?
Use a risk-based schedule and test material changes to identity, permissions, tenant isolation, hosting or sensitive workflows. After fixing a significant finding, verify the original path and related variants rather than waiting for the next periodic assessment.
Published 27 October 2026. Original Atlant Security analysis and illustrations, with primary references linked beside the relevant guidance. Examples are illustrative. Confirm current platform requirements for the app and environment being assessed.
Need an independent assessment of your app? Our Shopify App VAPT service covers the app, APIs and agreed hosting environment, with one-time engagements starting at $7,000 USD. Build your testing scope for a fixed proposal.