The Shopify App Security & Access Audit Playbook: Verify permissions, developer evidence, and ownership before peak season

Turn this week's security announcement into an ownership check

Shopify's October 20, 2026 app-security announcement asks developers to review their applications now. For merchants, the practical response is to identify who can change store data, what those applications support, and who can produce evidence that the access is controlled. This is preventive work. The announcement is not proof that a particular app or store has been compromised.

Shopify has also announced future changes to storefront-code boundaries, IP restrictions, and App Store security requirements. Those items do not yet have launch dates in the announcement. Do not build a readiness plan around protections that have only been announced. Start with the access information and developer checks available today.

This playbook proposes a merchant-led evidence review, with technical work assigned to the people who operate each application. It is separate from an app-cost cleanup or a checkout fraud review. The goal is a short, accountable record of permissions, security work, and business continuity before peak trading makes changes harder to coordinate.

Inventory the business dependency before changing access

Create one entry for each installed third-party app and each custom integration. Record its business owner, developer or vendor, support contact, critical workflow, data categories, write access, and fallback procedure. Add the date evidence was requested, the next decision, and the person responsible for it. A shared register is more useful than a pile of screenshots that nobody owns.

Shopify's app-management guidance explains the Activity and permissions view under Settings, Apps, and the selected app. It separates view and edit permissions and shows recent activity. Permissions not used in the past 30 days appear separately. Activity tracking currently covers third-party apps rather than Shopify-built apps. The Privacy section describes personal-data categories and links the developer's policy.

Treat that view as the start of a conversation, not a complete risk assessment. A seasonal gifting tool may legitimately have little recent activity. An order-export app may work entirely in the background. Ask the business owner what would fail if it stopped, then verify that dependency before removing anything. Our app-stack rationalization playbook covers the broader consolidation decision; here, the priority is explaining and governing access.

Prioritize consequential permissions without inventing a risk score

Review applications that can change important store records early. Product publishing, discounts, orders, and customer records have different operational consequences, so ask what each permission enables in this specific store. This is an editorial prioritization approach, not Shopify's official severity classification. Read access can also be consequential when it exposes sensitive business or customer information.

Consider an illustrative merchandising app that can edit products even though the team now uses it only for reporting. The right next step is to ask the vendor whether editing is still required by an active feature and whether a narrower supported configuration exists. Do not assume a permission can be toggled off safely from the merchant admin or that the vendor can remove it without a release.

Record a disposition for every unexplained permission: justified by a named workflow, awaiting clarification, scheduled for a tested change, or approved for removal after dependency checks. Avoid a binary safe-or-unsafe label based on familiarity, an App Store listing, or a quiet activity chart. The useful result is an answer a second operator can understand and revisit.

Ask vendors for evidence that applies to the running release

Send a focused request to the vendor supporting each critical public app. Ask who owns security response, which production release was reviewed, when it was reviewed, what kind of review was performed, and whether material findings remain open. Request a short dated summary and an accountable contact rather than confidential source code, customer records, or credentials.

Shopify introduced its AI Toolkit security check on October 15. It supports public and custom applications across frameworks and provides findings with locations, severity, and remediation guidance. Shopify explicitly cautions that a clean result is not a guarantee of security. A vendor's statement that it ran a tool is therefore useful evidence of a step, not a certificate that closes the review.

Make the request proportionate. A small utility and a business-critical integration may warrant different depth, but both need a reachable owner. If a vendor cannot share detailed findings, ask for the scope of the review, remediation status, and any customer action required. Separate an unanswered question from a confirmed vulnerability, and escalate uncertainty according to the workflow's importance rather than making an unsupported accusation.

Apply the January token deadline to the right applications

Shopify's current offline-token migration guide and security guidance establish the deadline: starting January 1, 2027, Shopify will reject GraphQL Admin API requests from public apps that use non-expiring offline access tokens. New public apps already cannot use them. This enforcement applies to GraphQL Admin API requests and explicitly excludes custom apps and merchant-created apps. It is not a blanket January deadline for every integration.

For an affected public app, ask the vendor to confirm both new token issuance and migration of existing installations. Changing the new-installation path alone does not establish that a store already using the app has migrated. The guide provides a migration route for background-only installations without an active user session; performing it invalidates the old token for GraphQL requests. The app developer must own that implementation and storage, not a merchant copying tokens into an email.

Request a dated readiness statement for your installation and a plan for any required merchant reauthentication. Ask how a background job behaves when authentication fails and how the team notices before customers are affected. Those are proposed acceptance questions, not claims that every vendor needs the same release or that a January change should be deferred until the last trading day of December.

Give custom applications a separate technical workstream

A custom application's exemption from the public-app deadline does not settle its security posture. Assign the review to the developer who maintains its code and infrastructure. Agree on the application, deployed revision, environments, and interfaces included before treating the result as production evidence. A review of an old branch or only the storefront widget leaves other components unanswered.

The security-check guide separates deterministic local inspection from agent-assisted review. Running the command alone does not complete the latter. Git-ignored files are skipped by default, and some deterministic checks are specific to Shopify's React Router template. Ask what was actually inspected and what needed a separate review. Relevant findings include missing authentication, unauthorized cross-shop data access, excessive scopes, and leaked credentials.

Have the developer connect each finding to a fix or documented mitigation, then test and rerun the review against the intended release. Independently verify that normal workflows still work. For example, a controlled test should show that one shop's authenticated request cannot read another shop's records while legitimate requests remain functional. Never run cross-shop experiments against unrelated merchants or production customer data.

Native Shopify configuration and an externally hosted custom application have different ownership needs. Custom logic requires ongoing responsibility for hosting, access, deployments, monitoring, and recovery. Treat that maintenance as part of the engagement, not as an optional task after the original build. A scan is one input to that operating model; it does not replace a qualified review or live-system testing where warranted.

Use logs with their coverage limits in view

Ask the application owner to compare observed traffic with expected jobs, infrastructure, and operating hours. An unfamiliar source or unusual burst needs investigation, but it does not establish compromise by itself. Keep the question specific: which app, shop, interface, time range, and operation are being examined?

Shopify's Dev Dashboard monitoring documentation states that logs are retained for 30 days and a query can span up to seven days. Developers can filter by shop and filter GraphQL or REST requests by client IP. Wider queries can be sampled and large bodies truncated. Traffic directly between a customer's browser and an app backend is outside these Shopify logs. An empty result cannot prove that every application surface was quiet.

Capture relevant timestamps and identifiers promptly when investigating a concern, using the team's approved evidence handling. Ask the developer to explain coverage gaps and consult its own infrastructure records where necessary. Keep secrets and unnecessary customer data out of ordinary support threads. The order-sync reliability playbook provides a complementary view of monitoring business outcomes, which should remain visible while security changes are tested.

Protect continuity while resolving the findings

Before changing a critical app, define what success and failure look like. List the affected workflows, test data, person approving the change, verification steps, and an escalation path. Do not describe restoring an old credential as a rollback plan when that credential will no longer be valid. Have the developer explain the supported recovery route for the exact change.

Use a representative controlled test: authenticate, complete the relevant read or write, allow the background process to run, and verify the resulting business record. For a reporting app, check that the expected report still refreshes. For a catalog tool, verify the intended product update without changing unrelated records. These are illustrative tests to adapt, not a recommendation to experiment with live payments, messages, or fulfillment.

Shopify's October 20 guidance also calls for protecting development accounts with two-step authentication, removing unnecessary access, and maintaining a reachable emergency developer contact. Confirm who owns those controls across the vendor's operating environment. The merchant's decision record should say who can respond, not contain copies of account secrets.

If evidence suggests an actual incident, stop treating the work as a routine readiness checklist and involve the responsible security team and Shopify through official channels. Preserve the facts and let the appropriate owners determine containment and notifications. Do not promise that a scan, permission change, or uninstall resolves an incident without verification.

Finish with a small, auditable acceptance record

Close the review when each critical application has a named business owner, a current vendor or developer contact, an explained access scope, and a documented next action for unresolved findings. For applicable public apps, include dated confirmation of migration readiness for existing installations. For custom applications, identify the reviewed revision and the owner of any remaining remediation.

Keep uncertainty visible. An entry can be awaiting vendor evidence without being declared compromised. A mitigation can be accepted for a defined period without being called a permanent fix. Set the next review around the relevant release or unresolved decision, and make sure an absent developer does not leave the business without a contact.

A useful first session is narrow: choose the applications behind your most consequential daily workflows, inspect their permissions, and send evidence requests to their owners. That creates a concrete queue the team can finish. Expand from there instead of attempting an indiscriminate pre-peak rebuild.

The outcome is operational clarity: who has access, why they need it, what has been checked, and what happens when something fails. Keep the register current alongside the routines in our post-launch operations playbook. Security readiness becomes more dependable when it is maintained with the store, rather than reconstructed only when a deadline arrives.