Shopify asks every app developer to act on security steps now

What changed

On 20 October 2026, Shopify published a changelog post, "Securing your app, together", asking every app developer to act on a list of security steps that week. Shopify says attacks are increasing across the app ecosystem, in line with the rest of the industry, as AI gets better at finding vulnerabilities. It calls security the most important thing developers can work on right now.

The post is flagged Update and Action required, and applies to the Platform surface. It names no API version and lists no affected APIs.

Shopify also says it is taking its own steps: tightening the boundaries for storefront app code, adding IP address restrictions so that app keys only work from the developer's servers, and raising App Store security requirements. It says it will share details and timelines before any change takes effect. The post gives no dates for these changes, so none are known yet.

Who is affected

Shopify's changelog asks every app developer to act on the security steps it lists. It does not limit the request to a type of app, a category of developer or a set of API versions.

Some steps have a narrower scope:

• **Expiring offline access tokens:** the requirement applies to public apps making GraphQL Admin API requests. New public apps already cannot use non-expiring tokens. Shopify does not enforce it on custom apps or apps created by merchants. The changelog says the requirement will soon apply to all public apps.

• **Script tags:** the security best practices page says script tags are deprecated and will stop running on storefronts on 1 March 2027. If your app loads code through script tags, this affects you. Shopify recommends theme app extensions, or a web pixel if the script only collects analytics or conversion data.

The changelog also says Shopify will tighten the boundaries for storefront app code, add IP address restrictions for keys and raise App Store security requirements. It gives no dates or scope for these changes, so it is not yet clear which apps they will affect.

What to do

Shopify's changelog lists eight steps and asks every app developer to act on them this week. Work through them in this order, or split them across your team.

• Run the security scan. Use the one-prompt check in Shopify's AI Toolkit to look for Shopify-specific problems such as unauthenticated routes, cross-shop data access and unverified webhooks. Shopify says most partners in early access found something they did not know about. The best practices page notes that the checks read your source code and do not test the running app, so a clean result is not proof of security. Run them again on every release.

• Move to expiring offline access tokens. Start now, because Shopify says this will soon be required for all public apps. The steps are in the migration section of this article.

• Scan all endpoints. Use vulnerability scanners to check that every endpoint of your app is secured.

• Treat rendered data as untrusted. This applies whether it comes from metafields or your own servers. Escape and sanitise inputs for the context they are rendered into. In Liquid, the best practices page says output is not escaped for you: use escape in HTML, json inside a <script> tag and url_encode in URL parameters. Never execute a string supplied by a store owner or user as code.

• Check your API activity. Look at your requests in the Dev Dashboard and watch for anything suspicious. The Client IP filter shows traffic by originating address.

• Turn on two-step authentication for your Partner account, hosting, CDN, code repositories and email. Remove access for anyone who no longer needs it.

• Update your emergency contact. Make sure the emergency developer email in the Partner Dashboard reaches someone who can act quickly.

• Review the security best practices in Shopify Dev Docs and apply them.

Migrating to expiring offline access tokens

How you migrate depends on how your app requests tokens today. Newly scaffolded apps already request expiring tokens through the expiringOfflineAccessTokens flag, so this applies mainly to existing apps.

Apps built from an app template

If your app uses @shopify/shopify-app-remix or @shopify/shopify-app-react-router, add the flag to your shopifyApp() configuration and redeploy with shopify app deploy. The template then issues, stores and refreshes expiring tokens automatically.

const shopify = shopifyApp({
  // ...
});

const shopify = shopifyApp({
  // ...
  future: {
    expiringOfflineAccessTokens: true,
  },
});

Apps using token exchange or the authorization code grant

If your app implements either flow itself, add expiring=1 to the request that obtains the access token. From the response, store the access_token and refresh_token, along with expires_in and refresh_token_expires_in. Use the refresh token before expires_in seconds elapse, then store the new refresh token that comes back and use that one next time.

curl -X POST \
  https://{shop}.myshopify.com/admin/oauth/access_token \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'client_id={client_id}' \
  -d 'client_secret={client_secret}' \
  -d 'code={authorization_code}' \
  -d 'expiring=1'

Migrating existing installations directly

Existing installations migrate when your app acquires and stores an expiring token pair. If you don't want to wait for users to open your app, or your app is background-only (webhook consumers, app proxy backends, Flow actions), use the direct migration request. It sends the stored non-expiring token with your client credentials as subject_token, and needs no ID token or user session. Both requested_token_type and expiring=1 are required.

If you lose the response, repeat the same request with the original token and valid client credentials within seven days of the initial exchange. Eligible retries return the same token pair. Recovery stops once your app refreshes the issued pair or a later token acquisition for the same store retires it. If a retry returns invalid_subject_token, acquire a new token through ID-token exchange or the authorization code grant.

Reviewing API activity and handling a suspected issue

The changelog asks developers to check the Dev Dashboard for API requests and make sure there is no suspicious activity. The **Logs** view in the Dev Dashboard lists Admin API requests alongside webhook deliveries, Function runs, UI extension errors and your own app events.

What to look at in Logs

• Filter by Type, choosing GraphQL request or REST request. Both types can be filtered by Client IP and User agent, as well as Status and Target.

• Use Client IP to look at traffic from different originating addresses. The best practices page says to look for requests from outside your own infrastructure, since a leaked access token that is being used shows up as API traffic your app did not send.

• Use Shop to narrow to one merchant's store, and open an entry to see the API version requested, how long the call took and, for GraphQL, the query cost.

Logs only record what Shopify sees. A request a merchant's browser makes straight to your own backend never appears, so an empty timeline is not proof that nothing happened. Review your own server logs as well.

If you suspect a security issue

Notify Shopify immediately at partner-security-reports@shopify.com. The changelog says you are accountable for fixing the problem and notifying affected merchants, and that Shopify will support you through it. For general security enquiries, contact Shopify Support.

The best practices page says that if you find signs of a compromise you should follow its "When something goes wrong" steps. The source provided does not include the text of those steps, so check that page directly. It also says to revoke or rotate an exposed secret immediately, without waiting for confirmation that someone used it.

Deadline

The changelog, published on 20 October 2026, sets no calendar deadline for its own steps. It asks developers to act "this week". That is a request made at the time of announcement, not a date. It also gives no dates for the planned changes to storefront app code boundaries, IP address restrictions or App Store security requirements, and says details and timelines will be shared before any of them take effect.

On expiring tokens, the changelog says only that they will "soon" be required for all public apps. The migration page gives the date: from 1 January 2027, existing public apps can no longer use non-expiring offline access tokens for GraphQL Admin API requests. New public apps already can't.

This enforcement applies to GraphQL Admin API requests only. It does not apply to custom apps or apps created by merchants. The Dev Dashboard also lists a "Deprecated offline token" alert, shown as a warning while a non-expiring token approaches its deadline and as critical once it has passed.