Shopify asks app developers to act on security this week

Shopify is asking every app developer to review security this week. Its 20 October developer announcement combines immediate checks with plans for tighter storefront code boundaries, restrictions on where API keys can be used, and higher App Store security requirements.

For merchants, the practical question is what their app providers have checked and how they will communicate a confirmed problem. An unavailable App Store listing is a reason to ask questions, but it does not establish that the app was breached.

What developers should do now

Shopify’s checklist covers eight areas:

1. Run the AI Toolkit security prompt to look for Shopify specific weaknesses, including unauthenticated routes, access across shops and unverified webhooks.
2. Start migrating to expiring access tokens to limit the consequences of a leaked token.
3. Scan every app endpoint for vulnerabilities.
4. Escape and sanitise rendered data, including values from metafields and the app’s own servers.
5. Review API activity in the Dev Dashboard and use its Client IP filter to investigate unfamiliar sources.
6. Enable two step authentication across Partner, hosting, CDN, repository and email accounts, and remove access that is no longer needed.
7. Ensure the emergency developer email reaches someone able to respond promptly.
8. Apply the security practices in Shopify’s developer documentation.

This extends beyond running one scanner. A useful internal follow-up is to assign an owner to each check, record what was reviewed and track unresolved findings. Scanner output needs investigation; completion of a prompt is not evidence that an app is secure.

What Shopify plans to change

The company says it is tightening the boundaries for storefront app code, adding IP address restrictions so keys work from developers’ servers, and raising App Store security requirements. It promises details and timelines before changes take effect. The announcement does not provide those dates or a finished implementation specification.

Developers can prepare an inventory of their hosting arrangements and API traffic while waiting for that detail. They should not assume a future platform control replaces checks on the requests their own application accepts.

Delisting is not a breach verdict

Responding to discussion of a community list of 135 delisted apps, Shopify president Harley Finkelstein said most delistings are unrelated to security. The list is not an official count of compromised apps, and this article does not treat it as one.

“We delist for lots of reasons, most of them unrelated to security.”

Harley Finkelstein, 20 October 2026

Harley Finkelstein’s response, 20 October 2026

Read the original response on X if the embed does not load.

Questions merchants can send their providers

Ask whether the provider has reviewed Shopify’s checklist, who handles urgent security reports, and whether any confirmed issue affects your store. If an app is unavailable, ask the provider for its explanation and recovery plan instead of inferring a cause from a social post.

Review which installed apps still serve a business purpose and test critical shopping journeys. Plan any removal carefully around the functions involved, especially consent, search and checkout. If a provider confirms an incident, follow its specific remediation instructions and Shopify’s guidance.

Shopify tells developers to report suspected app security issues immediately through the contact in its announcement, fix the problem and notify affected merchants. That responsibility is separate from a listing’s availability.

21 October clarification: ownership and output safety

Shopify app development PM Nick Wesselman has reinforced the metafield warning: use app owned data and treat rendered values as potentially malicious. These are complementary controls.

Shopify’s metafield documentation distinguishes app owned namespaces from merchant owned data shared with appropriately scoped apps. App owned data is read only for merchants by default, but an app can configure merchant write access. Check the actual permissions rather than assuming the namespace makes every value trustworthy.

The Liquid escape filter escapes HTML special characters. That reference does not establish a universal sanitiser for JavaScript, CSS or every output context. Audit where each value is rendered; do not treat changing its namespace as permission to execute it raw. The warning does not identify the cause of a breach in any named app.

Nick Wesselman’s metafield safety warning

Read the original warning on X if the embed does not load.