The reason it gives is simple: attacks on apps are going up as AI gets better at finding holes. Shopify calls security "the most important thing you can work on right now". Fair enough.

Most of the post is a checklist, and most of the checklist is sensible housekeeping. One item has a hard date attached, though, so let's start with that.

Expiring access tokens, and the 1 January 2027 deadline

When an app is installed on a Shopify store, it gets an access token. That's the key the app uses to read and change things in your store: products, orders, customers, whatever it was given permission to touch. For years, the usual "offline" token never expired. Once issued, it worked until someone uninstalled the app or rotated it.

The problem with a key that never expires is obvious. If it leaks (from a log file, an old backup, a repository someone forgot was public), it keeps working. Shopify's line on this is short: "Short-lived tokens limit the damage if a token leaks."

So Shopify is moving public apps over to expiring offline tokens. Instead of one permanent key, the app gets an access token plus a refresh token. When the access token runs out, the app uses the refresh token to get a fresh pair. A leaked token goes stale.

Here's what the migration guide actually says:

  • New public apps already can't use non-expiring tokens.
  • Existing public apps can't use non-expiring tokens after 1 January 2027. After that, merchants lose access until they re-authenticate.
  • The rule is enforced on GraphQL Admin API requests.
  • It doesn't apply to custom apps or merchant-created apps.

That last point matters. If you've got a custom app built just for your store, this particular deadline isn't yours. If you sell or run a public app, it very much is, and ten weeks with Christmas in the middle isn't long.

What the migration involves

If your app is built on Shopify's own app template, the change is close to a setting: switch on the expiring tokens option and deploy. If it was built some other way, there's more to it.

Shopify gives you a way to swap each stored non-expiring token for an expiring one without the merchant having to do anything. Once swapped, the old token stops working for GraphQL Admin API requests. There's a seven day window to repeat the request if your app loses the response, which is a nice touch.

The bits that tend to catch people out are the ones the docs warn about:

  • Every refresh gives you a new refresh token. You have to store it and use that one next time. Keep using the old one and you'll get a 401, and the merchant has to reopen the app to log in again.
  • A 403 can mean a rejected non-expiring token or a missing permission. Check the message before you assume which.
  • If you rotate your client secret, you need to replace stored tokens too.

None of this is hard. It's the sort of work that's quick when the person who wrote the app is still around, and much slower when nobody quite remembers where the tokens are stored. If that sounds familiar, we've written a guide on what to do when your developer has left, and getting hold of keys and access is near the top of it.

The rest of the checklist

The other items in Shopify's post apply to pretty much anyone with an app, public or custom. In plain terms:

  • Run a security scan. Shopify's AI Toolkit has a security check that looks for Shopify-specific problems like unauthenticated routes, data leaking between shops and unverified webhooks. Shopify says that in early access "most partners found something they didn't know about". We covered what that check does and doesn't catch last week.
  • Treat rendered data as untrusted. That includes metafields and data from your own servers. Escape it and sanitise it.
  • Look at your API logs. The Dev Dashboard lets you filter logs by client IP, which makes odd traffic easier to spot.
  • Turn on two-step login everywhere. Partner account, hosting, CDN, code repositories and email.
  • Remove people who no longer need access. Old freelancers, former staff, the agency you stopped using in 2023.
  • Check your emergency developer email. It's in the Partner Dashboard, and it needs to reach someone who can act quickly. Not a shared inbox nobody reads.

Shopify also says it's tightening things on its side: tighter limits on what storefront app code can do, IP address restrictions so keys only work from your own servers, and higher security requirements for the App Store. It says it'll share details and timelines before those take effect. No dates yet, but it's a fair hint about where things are heading.

What I'd do this week

If you're a merchant rather than a developer, you don't need to read the token docs. You do need answers to a few questions:

  • Which apps on our store were built for us, and who looks after them now?
  • Are any of them public apps that need the token change before 1 January?
  • Who has access to the code, the hosting and the Partner account, and do they all still need it?
  • If Shopify emailed about a security problem with our app tomorrow, who would get that email?

If you can answer all four in five minutes, you're in better shape than you might think. If you can't, that's your job for this week, before the token change or anything else.

The two-step login and access clear-out are free and take an afternoon. The scan is free too. The token migration is a small, defined piece of development work. None of it needs a big project, but all of it needs someone to own it.

If you'd like a hand, we do custom Shopify app development, including picking up apps someone else built, and our support and maintenance plans cover exactly this kind of platform change so it doesn't land on your desk. Drop us a line or book a quick call and we'll tell you honestly how much work your app needs.

Cheers, Rob