A Shopify app can put hundreds of stores behind the same backend, deployment pipeline and support console. That makes its security a question of shared access: what could one compromised account, endpoint or release change across those stores?
Shopify app security covers the code you ship, the infrastructure you operate, the permissions merchants grant, and the people who can alter the service. A secure Shopify storefront does not automatically make an external app backend secure. This guide explains how to build those boundaries, where they commonly fail, and what to verify before the next release.
For app developers and technical owners. If you are choosing apps for a store rather than developing one, use the supplier questions below and our ecommerce cybersecurity service. For hands-on validation, see Shopify app penetration testing; for a documented control review, see the Shopify app security audit methodology.
Where Shopify’s responsibility ends
Start with an architecture inventory, not a list of security products. Identify every place your app receives requests, stores information, runs background work or publishes content. An app with a hosted backend has different responsibilities from an extension-only app. A merchant’s custom integration can also have a smaller distribution footprint without having a smaller data exposure.
For each component, record its owner, production location, data handled, credentials available to it and upstream dependencies. Include forgotten preview deployments, old API versions, public storage buckets and the support tool used to investigate merchant tickets. The important boundary is who can change merchant data or code, not which component has the most prominent hostname.
Shopify’s App Store security requirements cover matters such as web vulnerabilities, TLS and unnecessary exposed services. Meeting an entry requirement is useful evidence, but it does not establish that every later release, cloud permission or staff workflow remains secure. Treat platform review and your own ongoing assurance as separate activities.
Make the store boundary part of every operation
An authenticated user is not automatically authorized to retrieve every record the app can access. The backend needs to establish the caller’s identity, the store context and permission for the requested action. Do this before selecting an access token or reading a merchant record. A store name supplied in a URL is routing input, not proof of identity.
For embedded admin apps, Shopify now calls the short-lived App Bridge JWT an ID token; older code and documentation may call it a session token. It authenticates requests to your app and is distinct from the access token used for Admin API calls. Validate the relevant claims with maintained libraries rather than treating a successfully decoded JWT as verified.
Carry the verified store context through exports, queues, caches and download links. A safe API handler can still enqueue an unsafe job if the worker later resolves a file using its ID alone. Use test fixtures for two stores and verify both immediate responses and delayed artifacts. Shopify’s tenant-scoping guidance explicitly extends beyond front-door API routes.
Keep support impersonation separate from normal merchant access. Require an explicit reason, narrow duration and attributable audit record. A support account that can switch stores without a trace becomes a powerful route around otherwise sound isolation.
Secure hosting means more than choosing a reputable provider
A managed platform may maintain the operating system while leaving your team responsible for environment variables, service identities, database exposure and deployment permissions. On virtual machines, the same review also includes patching, administrative access and the runtime configuration. Serverless hosting removes some server-management tasks; it does not remove authorization or secret-management work.
A practical hosting review should establish:
- Ingress: which hostnames reach the app, whether an origin or provider URL bypasses the intended controls, and which endpoints genuinely need public access.
- Service privileges: whether a web process can read every secret, change its own deployment or administer the database when it only needs selected records.
- Environment separation: whether a developer preview shares production credentials, data or an administrative identity.
- Recovery: whether the team can restore a usable service and its configuration, with tested access to keys and backups during an incident.
Shopify recommends a hardened public ingress with private supporting services. Verify the effective network path rather than relying on a dashboard label that says “private.” Where AWS hosts the application, an AWS security assessment can address the cloud configuration alongside the application review.
Where a WAF helps—and where the app must decide
A web application firewall can reject recognizable attack patterns, constrain abusive request rates and provide useful traffic evidence. It cannot reliably decide whether a valid-looking export request belongs to Store A or Store B. That decision requires the app’s authenticated context and authorization rules.
Test both protection and availability. A challenge page that blocks a merchant’s browser may be recoverable; a challenge page returned to a webhook sender can quietly stop business processing. Use narrowly scoped exceptions, preserve server-side verification and monitor delivery failures. Cloudflare’s managed-rule troubleshooting guidance documents false positives, false negatives and direct-origin exposure. WAF coverage needs verification, not a checked box.
Protect tokens and authenticate asynchronous work
Separate the app’s client secret, store access tokens, refresh tokens and workload credentials in the inventory. They serve different purposes and have different recovery procedures. Restrict who can read them; redact them from logs, exception reports and support exports. Record how rotation works without leaving old credentials active indefinitely.
As documented on 27 October 2026, Shopify states that public apps must migrate away from non-expiring offline tokens for GraphQL Admin API requests before enforcement begins on 1 January 2027. Confirm the current offline-token requirements for your app. Exercise refresh failure, concurrent refresh and recovery paths before rollout; shortening token life does not help if refresh credentials are exposed in the same logs.
Where your hosting supports stable outbound addresses, Shopify’s Admin API IP restrictions provide another boundary around stolen tokens. Plan for deployment, failover and background-worker egress before enabling an allowlist.
For HTTPS webhooks, verify the HMAC over the original request bytes before trusting the payload. Authentication and duplicate handling are separate controls: a genuinely signed delivery can arrive more than once. Design the business operation so retries cannot issue a second benefit or duplicate a state transition. Shopify documents these requirements in webhook delivery verification. EventBridge and Pub/Sub integrations use their own delivery and access controls; do not copy an HTTPS verification design onto a different transport without reviewing it.
Common breach paths to model
The following scenarios are hypothetical failure patterns, not claims about a particular app or a ranking of incident frequency. Their value is in connecting a small control failure to the stores and data it can affect.
Cross-store access through an ordinary feature
An export feature accepts a record identifier, produces a file and returns a download link. The synchronous request appears correctly authenticated, but the worker or download handler fails to check ownership. The consequence is access to another tenant’s export without needing a server exploit. Review the whole workflow, including storage authorization and expiry, rather than only the first endpoint.
Stored content becomes executable storefront code
A design setting moves from an administrative form into a rendered theme component. If the app treats arbitrary stored content as trusted markup or script, the ability to change a setting may become the ability to change what shoppers execute. Use structured settings, context-appropriate output handling and explicit ownership of stored values. Shopify’s app-owned metafield guidance is relevant when settings can otherwise be modified through another actor or integration.
A release credential reaches more stores than an app credential
A compromised source-control or deployment account may change the version delivered to every tenant. Cloud IAM and CI/CD permissions therefore belong in an app-security review. Ask who can approve a release, replace an artifact or modify a build secret, and whether one account can perform all three without review.
Build secure software development into the release path
Use automated checks to make recurring decisions cheap, then reserve human review for authorization, sensitive business flows and changes to trust boundaries. A clean dependency scan says little about whether a new support feature can access all stores. A successful pentest of last month’s release does not approve a new token-storage design.
For each meaningful change, keep a short record of the security requirement, negative tests, reviewer and deployed artifact. Add tenant-isolation tests whenever introducing a new record type, queue consumer or export. Review build permissions when adding third-party actions. Keep a way to identify which merchants received an affected version and to roll it back safely.
Shopify’s dependency and runtime guidance addresses supported versions and release dependencies. The NIST Secure Software Development Framework provides a broader structure for embedding security work in development. Neither substitutes for a team member owning the exceptions and unresolved findings.
Log decisions, prepare recovery and reduce retained data
Logs should let the team connect a sensitive action to its tenant, actor, job and release without copying customer data or credentials into the logging platform. Useful events include privileged support actions, unusual export activity, failed tenant checks and deployment changes. Test whether an alert reaches an accountable person and whether that person can investigate it.
Keep a data inventory that includes logs, analytics, backups and third-party processors, not only the primary database. Specify retention and deletion behavior for each destination. Shopify’s protected customer data requirements make minimization and protection relevant to the app’s data access, but a field-level approval is not evidence that every downstream copy is controlled.
Prepare response actions that distinguish a compromised merchant account from an app-wide release or credential incident. Record who can pause a risky feature, rotate relevant credentials, preserve logs and assess affected stores. Follow Shopify’s incident guidance and your applicable notification obligations. For specialist support, our incident response team can help scope containment and investigation.
Questions to ask an app supplier
- Which merchant data do you retain outside Shopify, and where does it go?
- How was cross-store access tested across APIs, exports and background jobs?
- What can your support team access, and how are those actions approved and logged?
- What did the latest independent assessment include, exclude and leave unresolved?
- How do you respond if a release or credential affects more than one store?
Ask for scoped evidence rather than an unqualified “secure” answer. A useful response identifies the assessed release, systems, testing dates, remediation status and limitations. Your own review should follow the data and permissions your store actually grants.
Shopify app security questions
Does Shopify host every app’s backend?
No. App architectures differ. Many apps operate an external backend and data services; some extension-only apps do not. Establish who operates each component before assigning security responsibilities.
Is a WAF enough to secure an app?
No. It is one layer. Store isolation, authorization, token handling, release permissions and recovery need controls and verification of their own.
Where should a small app team start?
First establish who can reach merchant data and deploy code. Then verify tenant isolation, protect credentials, remove unnecessary public services and test recovery. Use the audit guide to turn those priorities into an evidence-backed review.
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.