On Oct 27 we recommended the IP allowlist. It is now required for every public app by November 20, or November 12 if you use bulk ops. An IP allowlist means a leaked token can’t be used anywhere but your own servers. With the busiest weeks of the year for merchants almost here, we’re asking for it now.
Action required
All public apps that call the Admin API: Turn on the IP allowlist by November 20, 2026 at 11:59 PM ET. With it on, your tokens only work from the addresses or networks you list, so a leaked token can’t be used anywhere else. The IP allowlist is required for public apps. If you’re on serverless or dynamic IPs, you’ll need to allowlist by network with ASN support instead.
Bulk operations: Turn on the IP allowlist by November 12, 2026 at 11:59 PM ET. After that date, bulk queries and mutations from public apps without an IP allowlist are blocked.
Also this week
Merchants can now see your app’s security setup in Settings > Apps: expiring tokens and IP allowlist. After November 20, apps without an IP allowlist are flagged.
Find non-expiring tokens fast: filter your Dev Dashboard API logs by token type. And our Token Expiry FAQ answers the most common questions.
Network access testing in dev store previews: You can now test your network_access declarations before you release. It flags any site or server your app uses that you haven’t declared yet. Test network access in dev store previews
Run app security checks in CI/CD. A new tutorial walks you through how to automatically scan your app for security issues.
Coming soon, access scopes for bulk operations: Bulk queries and bulk mutations will each need their own scope. If your app ran a bulk operation in the last 180 days, Shopify grants the scopes automatically. Once they’re live, add them to your app config before your next deploy. We’ll share the changelog with the scope names when ready.
If you miss a deadline
To protect merchant security, we’ll begin enforcing IP allowlists starting in November. The timelines for expiring offline access tokens remain the same. In both cases, existing installs keep working until April 1, 2027:
IP allowlist
Expiring offline access tokens
Bulk queries and mutations blocked
November 12, 2026
Delisted from the App Store, no new installs
November 20, 2026
January 1, 2027
Flagged in merchant Settings > Apps
November 20, 2026
January 1, 2027
Merchants see a warning in their admin
January 15, 2027
January 15, 2027
Admin API requests fail
April 1, 2027
April 1, 2027
Get help
If you see something suspicious, tell us right away at partner-security-reports@shopify.com. You’re responsible for fixing it and notifying affected merchants, and we’ll support you through it.
I haven’t read the documentation yet, but once it’s enabled, if we don’t touch it, it will remain? Can you confirm that as long as we don’t touch the IP settings, there is no risk of getting flagged?
I’m thinking of something like with the expiring token, if we use an old token by mistake it’s flagging the app.
I understand that the timing is bad. I too would rather this happen at any other time of the year. Timelines for required changes that are this short are rare for us, and I hope that the ecosystem takes that as a signal of how important the changes are.
We are working very hard to provide the tools for partners to adapt to the rapidly changing security landscape. Our hope – and frankly expectation – is that our partners will take it as seriously as we do. Don’t do this because we ask you to. Do this because you care about merchant data and not being compromised.
Nice improvement to enforce, especially in this new era of AI hacks (even though the timing is short, but the change should be easy).
One question though. In the email, it states : “Starting today, merchants can see which security measures each installed app has on in Settings > Apps, including the IP allowlist.”
Does this mean that merchants can see the specific IP addresses that we may have entered in the allowlist?
This may defeat what some of us are trying to do when we place our servers behind Cloudflare : hide the server IP so attackers can’t bypass Cloudflare’s security. But in this case, we could just enter the ASN (a bit less secure, but it’s okay I think).
Hey @Blair, just wanted to say I’ve successfully activated this on one of my apps!
The system works really well. I particularly like being able to test against previous API calls before enabling it. Took me about 30 minutes in total.
One small bit of feedback: the GraphQL dashboard only shows a maximum of 7 days of data and is pretty janky, whereas the test covers the last 30 days. This made it a bit tricky to cross-reference the results and work through my findings. It would be great if the dashboard could show the full 30 days to match the test!
Overall, a really straightforward process and a great security initiative.
The timeline is really tight, we run everything on Lambda… is gonna be tricky to find a reliable solution that quickly. Any guidance for Serverless architectures?
Great initiative! I love that there’s a “run test” button. It was really simple to enforce this for both of my apps.
Negative feedback from my side:
There’s no way to configure multiple access policies. I’d like to allow a static IP of my machine (used for support queries), as well as ASN of my apps’ hosting provider.
Even though the change was simple, I wish there was more time than a week (for those of us using bulk operations). I’m concerned I’ll miss one of these one day… Reading “On Oct 27 we recommended the IP allowlist” and on Nov 5 we make it a requirement doesn’t sound professional.
The problem is that my research (AI) is telling me the following:
There is no Lambda-specific ASN. Lambda functions outside a VPC egress from AWS’s regional public address pool, and that pool is announced from Amazon’s general ASNs, chiefly AS16509 (AMAZON-02, the main AWS network, and the one most regions resolve to) plus AS14618 (AMAZON-AES, which still covers a chunk of legacy us-east-1 space). Amazon announces from several ASNs, including AS14618, and AS16509 is the best-known but not the only one.
Interesting! I’m certainly no expert, but here’s how I did it. Not entirely sure if it’s the correct approach, though! And I’m not sure itll work for Lambda
If you open the Shopify IP blocking tool/page and run the test, you’ll probably see a bunch of blocked requests. You can then head over to the GraphQL API dashboard (there’s a link on the IP allowlist page), search for each blocked IP, and take a look at the requests.
If they all look legitimate and expected, you can click on one of the requests to find its ASN. You can then add that ASN to your allowlist, run the test again, and move on to the next one.
Hopefully, this will also let you see if there’s an ASN associated with your Lambda requests, which you can then add to the allowlist.
That’s basically the process I followed, and it seemed to work pretty well!
EDIT: This is just how I did it - the Shopify guys and official instructions will be better!
The first answer is “it’s complicated”. We do have a set of registered ranges in AS40509 but they may not be the addresses that are seen by servers being connected to. Instead, it’s likely they see the server’s IP address which isn’t assigned within that AS.
Not clear if that still holds. The post is from 2020 but there are other posts (one example) discussing how their block ranges are not stable. Old too.
Give this, if you’re on Fly.io it appears that the only solution is to pay for an egrees IP! Am I missing something?
But at the same time, it feels like Shopify has been nothing but reactive when it comes to these security issues and is now scrambling to address things that would have been addressed in the past if merchant data not being compromised was an “expectation”. Meanwhile, this comes off as quite patronizing to developers, to be honest.
Well given that with their default remix app setup, we literally add never-expiring offline tokens stored unencrypted directly in the DB… and this for years. I’d tend to agree with you
@Blair what happens on the 12th for dev version of apps if we don’t have IP or ASN to provide, given they run locally, we don’t have any. Will we still be able to send bulk operation for these dev apps after November 12th?
the notification is incorrect for expiring access token usage - we’ve migrated months ago, there are no warnings showing on the dev dashboard anymore. this needs to be fixed with urgency as it’s communicating undue panic to merchants.
The migration deadline is 31st December, and we still have roughly two months to go. There are plenty of developers, including myself, who are actively working on the migration. Why put this kind of unnecessary pressure on everyone?
Everyone will migrate before the deadline.
Come on, we’re already under so much pressure as developers. Please don’t involve merchants in this unnecessarily. If you really need to show this banner, at least wait until 31st December.
