Shopify Added a One-Command Security Scan to the CLI. Run It Before a Reviewer or an Attacker Does.

Shopify's Fall '26 Edition landed on October 28, and most of the noise is about agents and Shop Pay. The line that deserves more attention from developers is much smaller. The AI Toolkit now includes a single Shopify CLI command that scans your app for three specific problems: unauthenticated routes, cross-shop data access, and unverified webhooks.

If you build or maintain Shopify apps, those three are not random. They are the bugs that turn a small app into a merchant's worst week.

Why these three checks

Each one maps to a failure we see in real codebases.

Unauthenticated routes. An endpoint gets added for a quick admin action or a debug view, and nobody puts session validation in front of it. It works in development, so it ships.

Cross-shop data access. This is the scary one for multi-tenant apps. A request comes in with a shop domain or an ID, and the code fetches the record without checking that it belongs to the shop making the call. One merchant can read another merchant's orders by changing a parameter.

Unverified webhooks. If you don't check the HMAC signature, anyone who finds your webhook URL can post fake events. Fake orders/paid payloads are a fun way to trigger fulfilment or refunds that should never happen.

None of these are exotic. They're the boring bugs, which is exactly why a scanner is useful. Boring bugs survive code review because everyone is looking at the interesting parts of the diff.

What Shopify says happens next

According to the announcement, once the scan finds something, you can hand the findings to an AI coding assistant and fix them. That's a sensible loop. The scanner finds the route, the assistant proposes the middleware, you review it.

Here is our opinion on that last step: review the fix more carefully than the finding. An assistant that adds an auth check to one route will happily leave the three sibling routes alone. After any fix, re-run the scan and also grep for the same pattern elsewhere.

What a scanner will not catch

A static check like this is a floor. It won't tell you that your app stores access tokens in plain text, that a background job runs with broader scopes than it needs, or that a third-party library you pulled in last month phones home. It also can't judge intent. A route can be authenticated and still return far more than the caller should see.

So treat a clean result as "the obvious holes are closed", not "the app is secure".

How to use it properly

1. Run it locally before every pull request that touches routes, webhooks or data access.
2. Add it to CI so a failing scan blocks the merge. A check that only runs when someone remembers is a check that stops running.
3. Run it once now against your oldest app. The code nobody has touched in a year is where unverified webhooks live.
4. Write a test for each finding you fix. Otherwise the same hole comes back in the next refactor.

Shopify also changed what merchants see on collaborator requests, including how long a partner's organization has been on Shopify and roughly how many stores it works with. Merchants are getting more careful about who they let in. Your security posture is turning into part of how you win work, not just how you avoid incidents.

The takeaway

Security tooling that costs one command has no good excuse to be skipped. Run the scan, fix what it finds, and put it in your pipeline so it keeps running when the team gets busy.

We're here to help founders and teams design and build digital products that are built to scale with you, not slow you down. If you're looking to build something, get in contact with us today!