Every time you install a Shopify app, a screen appears listing what the app wants access to, things like “View your customers” or “Edit your products”, with a green Install app button underneath. Most merchants read the app name, glance at the star rating, and click through in under ten seconds.
That screen is not a formality. It’s an OAuth permission grant, and it’s the actual mechanism by which a third-party developer’s code gets a live connection into your store’s data: your customer list, your order history, sometimes your theme code itself. Given how many high-profile incidents in ecommerce over the past few years have traced back to a compromised or over-permissioned app rather than a flaw in Shopify’s core platform, it’s worth understanding what you’re agreeing to.
This post explains how Shopify’s app permission system actually works, what the common permission scopes really mean in practice, and gives you a practical way to audit the apps already sitting in your store.
How Shopify App Permissions Actually Work
Shopify apps connect to your store using OAuth 2.0, an industry-standard authorisation protocol also used by Google, Microsoft and most major software platforms. In Shopify’s implementation, permissions are called scopes, and they follow a consistent naming pattern: read_[resource] or write_[resource]. A scope of read_orders lets an app view order data. write_orders lets it create, edit or cancel orders. write_products lets it change your product catalogue, not just look at it.
When you install a public app from the Shopify App Store, the app’s developer has pre-declared which scopes it needs. Shopify shows you that list on the install screen, you approve it as a whole (Shopify doesn’t currently let you approve some scopes and deny others for a given app), and the app receives an access token scoped to exactly those permissions, nothing more.
There’s a second path worth knowing about: custom apps, built and installed by a merchant or developer directly for a single store via Settings > Apps and sales channels > Develop apps in your Shopify admin. With a custom app, you (or your developer) define the exact scopes it gets, which is one reason custom-built internal tools tend to be lower-risk than public marketplace apps, the permission surface is deliberately scoped to only what that specific tool needs.
Either way, the access token an app receives stays valid until you uninstall the app or the developer’s credentials are revoked. Installing an app isn’t a one-off event that grants a snapshot of your data, it’s an ongoing, live connection.
The Most Common Scopes and What They Really Mean
Scope names are reasonably self-explanatory once you know the pattern, but it helps to see what a few of the common ones actually enable:
read_products/write_products, view or modify your catalogue, including titles, descriptions, pricing and inventory levels. A pricing tool or inventory sync app needs this; a review-widget app generally shouldn’t.read_orders/write_orders, view or modify order data, including customer names, shipping addresses and line items. Fulfilment and shipping apps legitimately need this.read_customers/write_customers, view or modify your customer list, including names, emails and order history. This is one of the more sensitive scopes on the list.read_customer_events/read_analytics, visibility into on-site behaviour, sometimes used by marketing and personalisation apps.read_discounts/write_discounts, view or create discount codes, relevant to loyalty and promotion apps but also a common target for abuse if an app is compromised, since it can be used to generate fraudulent discounts.read_content, access to blog posts and pages.read_themes/write_themes, the ability to view or directly edit your theme’s Liquid, JavaScript and CSS files.
That last one deserves its own section.
Why Theme and Customer Data Scopes Deserve Extra Scrutiny
write_themes is one of the most powerful scopes an app can request, because it doesn’t just let an app use your store, it lets an app rewrite your storefront’s code. An app with this scope can inject or modify JavaScript that runs in every customer’s browser. Most apps that request it have a legitimate reason (page builders, currency converters and personalisation tools genuinely need to modify theme files), but it’s also the scope most associated with malicious script injection when a developer’s account or supply chain is compromised, the kind of incident that shows up in ecommerce security news as skimming code quietly harvesting checkout details.
Customer data scopes carry a different kind of risk: legal and reputational rather than technical. Under Australian privacy law, you, the merchant, remain responsible for your customers’ personal information even when a third-party app is processing it on your behalf. If an app with read_customers access suffers a data breach, that’s your customer data exposed, and depending on the scale, potentially your notification obligations under the Notifiable Data Breaches scheme. Shopify separates out access to more sensitive personal data (things like full customer profiles, or financial details) into what it calls protected customer data, which sits behind an additional approval tier on top of standard scopes, more on that below.
The practical takeaway: an app requesting write_themes or broad customer data access should have to justify why it needs that level of access for what it does. “It’s a free app so it can’t be that risky” is not a safe assumption, free apps still need a business model, and broad data access is sometimes part of it.
Shopify’s App Review Process (and Its Limits)
Public apps listed on the Shopify App Store go through a review process before they’re published, and Shopify has tightened this considerably in recent years. Apps that need access to protected customer data must apply separately for that access, and Shopify assesses the request against defined data protection levels before granting it, the more sensitive the data category, the more scrutiny the app and developer go through.
This is a meaningful safeguard, but it isn’t a guarantee. App review checks what an app says it does and whether its stated use case justifies its requested scopes at the point of approval, it doesn’t continuously monitor what an app does with that access afterwards, and it can’t prevent a legitimate developer’s credentials from being compromised down the line. Custom and private apps, by design, don’t go through Shopify’s App Store review at all, because they’re built for a single merchant rather than distributed publicly. The responsibility for whether an app’s permissions make sense ultimately sits with the merchant who approves them, which is exactly why periodically checking what’s installed matters.
How to Audit the Apps Already Installed on Your Store
Most stores accumulate apps faster than they remove them. A checklist you can work through in under an hour:
- Go to Settings > Apps and sales channels in your Shopify admin and list every installed app, including ones you’ve forgotten about from a past campaign or a developer who no longer works with you.
- Click into each app and check what it’s currently doing, is it actively used, or is it a leftover from a promotion or a theme you no longer run?
- Check the scopes it holds. For apps installed via the App Store, the original install screen listed the scopes; for a live audit, cross-reference what the app is for against what data categories make sense (a shipping label app shouldn’t need
write_discounts). - Review Settings > Data sharing in your admin, where Shopify surfaces which apps and partners have access to store and customer data, this is the fastest way to see the full picture in one place.
- Uninstall anything not in active use. An unused app with a live access token is pure downside, no benefit, ongoing risk.
- For remaining apps, check the developer. Established, well-reviewed developers with a clear privacy policy are a materially different risk profile to a low-review app from an unfamiliar publisher.
- Reassess after any store handover. If you’ve inherited a store from a previous owner, agency or freelancer, treat the existing app list as unverified until you’ve been through it, this is one of the most common gaps we find during a broader technical review.
That last point is worth sitting with. App permission sprawl is rarely caused by one bad decision, it’s the accumulation of a dozen reasonable-seeming installs over a couple of years, none of them audited again after day one. If you’ve never reviewed what’s connected to your store, or you’re not confident you could explain why each app has the access it has, that’s a sign it’s time for a proper look rather than a guess.
When to Bring In a Specialist
A quick self-audit using the checklist above will catch the obvious issues, stale apps, obviously mismatched scopes, forgotten integrations. What it won’t always catch is more subtle: theme code that’s been modified by an app that’s since been uninstalled (leaving orphaned script tags behind), scopes that look reasonable individually but combine into a broader risk profile, or data-sharing relationships buried in an app’s own settings rather than Shopify’s admin. This is exactly the kind of gap a Shopify audit is designed to catch, a structured review of your store’s technical health, including the apps connected to it, rather than a surface-level click-through.
FAQ
How do I see what permissions a Shopify app has?
In your Shopify admin, go to Settings > Apps and sales channels, then Settings > Data sharing to see which apps and partners have access to store data. For apps still installed, you can also open the app’s listing on the Shopify App Store to see its currently declared scopes, though this reflects the current version rather than necessarily what you approved at install time.
Can I change what permissions an app has without uninstalling it?
Generally no. Shopify’s permission model grants scopes at install time as a package; if an app’s developer updates the scopes it requests (for example, adding a new feature that needs write_discounts), you’ll typically be prompted to re-approve on the next update. To reduce an app’s access outside of that, uninstalling and, if needed, reinstalling with a narrower use case is the practical option.
What happens to app permissions when I uninstall an app?
Uninstalling an app revokes its access token, which should cut off its ongoing access to your store’s data going forward. It does not retroactively delete data the app may have already extracted and stored on its own servers, that’s governed by the app developer’s own data retention and privacy policy, which is worth checking before you install, not after.
Are free Shopify apps riskier than paid ones for permissions?
Not automatically, but it’s worth asking how a free app sustains itself. Some free apps are genuinely free as a loss-leader for a broader platform; others monetise through data access, upsells or affiliate arrangements baked into the permissions they hold. The price tag alone isn’t a reliable signal, the scopes requested relative to the app’s stated function are.
What’s the difference between a public app and a custom app in terms of permissions?
A public app is built for distribution to many merchants via the Shopify App Store and goes through Shopify’s app review process, including additional approval for protected customer data access. A custom app is built for a single store, typically by or for that merchant directly, and its scopes are defined deliberately for that one use case rather than reviewed by Shopify for public distribution, which can mean either tighter, purpose-built access or, if built carelessly, broader access than necessary.
Next Step
If you can’t confidently list what every app on your store has access to and why, that’s worth fixing before it becomes a bigger problem. Book a call with Nexly or start with a Shopify audit to get a clear picture of what’s connected to your store and what it can actually do.
