Shopify Store Security: Staff, Apps, Checkout and Fraud

Most Shopify stores are compromised through people and permissions rather than the platform: a phished owner account, a shared login, an agency collaborator who never left, or an app granted far more data than it needs. Shopify runs the infrastructure and checkout, but the merchant decides who can sign in, what each user and Partner can touch, which apps receive store data, what code runs around checkout and how risky orders are handled. This guide covers those merchant controls: account security and two-step authentication, roles and sensitive permissions, collaborator accounts, app review, checkout extensibility and fraud analysis. It is for store owners, ecommerce managers, agencies and the security teams who support them. App access tokens and client secrets are covered in depth in the Shopify App Tokens Security Guide. Facts are from Shopify's help centre and developer documentation, checked on 8 November 2026; features vary by plan, and the page notes where Shopify states a plan limit.

This is an independent guide from NHI Mgmt Group, based on Shopify's public documentation as of November 2026. It is not sponsored or reviewed by Shopify. Product features change, so confirm settings against Shopify's current documentation.

Key takeaways

The owner account is the crown jewel. Owners have full access, including to custom apps, so the owner login gets a passkey or security key and is never shared, even with staff.
Two-step authentication is a payments control too. Shopify requires it to use Shopify Payments and warns that payouts may be held without it; staff must enable it themselves unless the store can enforce it centrally.
Sensitive permissions belong to a few people. Shopify marks billing, payment settings, customer data requests and similar permissions as sensitive and advises giving them only to the most trusted users and splitting duties.
Collaborators are third-party access. Partner accounts arrive through a four-digit request code, receive a role you approve and expire after 90 days without login; regenerate the code and remove finished collaborators.
Every app install is a data-sharing decision. Limit who holds "Manage and install apps and channels", review scopes before approving, and prefer checkout UI extensions, which run sandboxed without access to payment data.

How identity and access work in Shopify

A store has four kinds of identity, each with different controls:

Identity	What it is	Main controls	Main risk
Store owner	The account that owns the store; full access	Passkey or security key, unique email, recovery details kept current	Phishing or credential reuse gives total control (ATT&CK T1078 Valid Accounts)
Staff users	Employees with their own accounts and assigned roles	Roles and permissions, two-step authentication, login history review	Over-broad roles, shared accounts, leavers not removed
Collaborators	Shopify Partners (agencies, freelancers) invited with a request code	Request code, approved role, 90-day inactivity expiry, removal	Standing third-party access (T1199 Trusted Relationship)
Apps	Public, custom or merchant-built apps holding access tokens	Install permission, scope review, protected customer data approval, uninstall	Over-scoped or abandoned apps; token theft (T1528 Steal Application Access Token)

Account hygiene from Shopify's guidance:

One person, one account: Shopify's account security guidance says each person who accesses the store should have a unique staff account with specific permissions, and the owner's credentials should not be shared with anyone, including staff.
Two-step authentication methods: authenticator apps, security keys, built-in authenticators and passkeys. SMS cannot be set up as a new method. Prefer passkeys or security keys for anyone with sensitive permissions. See the Phishing-Resistant MFA Guide.
Enforcement: staff turn two-step authentication on for their own accounts and the owner cannot switch it on for them. Shopify's user security settings let eligible stores enforce it from Settings, Users, Security, and Shopify Plus organisations get additional organisation-level security settings.
Phishing awareness: Shopify states that its Support requests sensitive documents only through a secure upload page on a shopify.com domain. Treat calls or messages asking for login codes, or documents via other routes, as social engineering (T1566 Phishing).
Public files are public: Shopify warns that Content, Files is for material meant to be public, such as product media. Never upload invoices, ID documents or exports there.

Admin roles and privileged access

Shopify permissions are grouped into roles, and roles are assigned to users. Permission types exist at store level, organisation level, Point of Sale level and, for Partner organisations, Partner level; availability depends on plan and sales channel. Some actions, such as user and role management, are not ordinary permissions and have their own requirements.

Sensitive permissions

Shopify identifies permissions that expose banking, financial and customer information. Its guidance is to assign them only to roles for the most trusted users, and to split sensitive administrative tasks across roles and users so no single account is a single point of failure.

Sensitive permission (Shopify name)	Category	Why it matters	Suggested holders
Customers, Request data	Store	Handles customer data requests, exposing personal data	Privacy or customer service lead
Finance, Edit billing payment methods and pay invoices	Store	Controls how the store pays Shopify and apps	Finance owner
Finance, Manage other payment settings	Store (also in POS)	Changes payment configuration	Finance owner plus one deputy
Business entities, View, View sensitive information	Organisation	Exposes business entity details	Finance and legal
Customer privacy, Shopify Network Intelligence	Administrator	Access to that intelligence feature	Store administrators only

Store and organisation administrator roles already include sensitive access, and Shopify-managed roles cannot be modified. Build custom roles for day-to-day staff instead of handing out Administrator.

Permissions that control app risk

Manage and install apps and channels: installing an app approves the scopes it requests, so this is effectively a data-sharing approval. Keep it to a small named group.
Approve app charges: controls paid installs and trials that convert to charges.
App development (Develop, Enable development, View apps developed by staff and collaborators): who can build custom apps with store tokens. Enable development should stay with the owner or platform lead.

Role design by store size

Store profile	Suggested model
Owner plus one or two staff	Owner holds sensitive and app permissions; staff get custom roles for orders, products and customers only; owner signs in with a passkey and keeps it off shared devices
Growing team with an agency	Separate roles for fulfilment, merchandising, marketing and finance; agency collaborators get a role limited to themes or specific apps; quarterly access review
Multi-store organisation (Plus)	Organisation roles for a small central admin team, store roles for local staff, enforced two-step authentication, sensitive permissions split between finance and privacy owners

Integrations, API tokens and service accounts

Collaborator accounts

Request code: a four-digit code under Settings, Users, Security. Give it only to the Partner you intend to work with. Use Generate new code in the Collaborators section to invalidate old codes, for example after each engagement.
Approve deliberately: each request arrives with an auto-generated role named "<Collaborator name>x<Store name>". Review and reduce its permissions, or assign an existing least-privilege role, before selecting Accept request. Reject unknown requests.
Built-in limits: collaborators must have two-step authentication to log in, cannot access Point of Sale, cannot be given the Administrator role and cannot receive store ownership. Each store gets a separate collaborator account.
Expiry and removal: access expires after 90 days without login and can be reactivated. Removal is permanent; the Partner must request access again. Their name stays in activity logs and order timelines, which helps investigations.

Collaborators do not count towards user limits, which makes it tempting to leave them in place. Treat them as third-party access under your supplier process. See the SaaS and OAuth App Governance Guide.

App review before install

Scopes: any write scope also grants read; order scopes cover the last 60 days unless read_all_orders is granted. Ask why an app needs write access or full order history.
Protected customer data: apps get no protected customer data (names, emails, addresses, phone numbers) from live stores until Shopify approves them in a separate review. An app asking for these fields should explain why.
Optional scopes drift: apps can request optional scopes after installation, so the scopes an app holds can grow. Review installed apps periodically.
Uninstall unused apps: an installed app keeps its access until uninstalled. Remove trials and apps from finished campaigns.
Custom apps: each is associated with a staff or collaborator account that receives its warnings; reassign it when that person leaves. Token storage and rotation are covered in the Shopify App Tokens Security Guide.

Checkout extensibility

Shopify's checkout and accounts editor customises the checkout, thank you, order status and customer account pages. Apps on the thank you and order status pages are available on Basic and Plus; apps on the information, shipping and payment steps and the Checkout Branding API are Plus only. Checkout UI extensions run in an isolated sandbox inside a Web Worker, without access to the checkout page's HTML, the DOM or sensitive payment information, and external network calls need the network_access capability. That model limits what a malicious or compromised extension can skim, compared with arbitrary script injected into a payment page. Review which extensions request network_access and what they send. For PCI DSS v4.0 obligations around payment page scripts (requirements 6.4.3 and 11.6.1), see the PCI DSS for E-commerce Payment Page Scripts Guide.

Logging and detection

Signal	Where	What to look for
Login history	Settings, Users, Security	Sign-ins from unexpected countries or devices, especially for the owner and sensitive roles
User and role changes	Settings, Users	New users, new collaborators, role edits adding sensitive permissions (T1098 Account Manipulation)
Collaborator requests	Users page, Requests filter	Requests nobody expected
App installs and scope changes	Apps settings; app/scopes_update webhook for your own apps	Installs outside change control, new optional scopes
Order timelines and activity	Order pages	Refunds, edits or cancellations by unusual users
Fraud analysis	Orders page risk warnings	Clusters of medium and high risk orders, repeated card attempts

Fraud analysis

Shopify rates eligible online card orders low, medium or high risk for chargeback due to fraud and shows a recommendation such as "Confirm with the customer before fulfilling" or "Consider canceling this order". Indicators include Address Verification System (AVS) results, whether the correct Card Verification Value (CVV) was entered, whether the customer's location matches the payment method, unusual device or network activity and multiple card attempts. Shopify says an IP address on its own is not a recommendation, and the number of indicators does not decide risk: follow the overall recommendation. For high-risk orders you can verify, cancel or refund, and manual payment capture buys time to investigate. Shopify Protect status is reviewed separately. Card issuers, not Shopify, decide chargebacks. Fraud indicators and third-party fraud apps need the Basic plan or higher; recommendations need Grow or higher, or Shopify Payments. Recommendations are not given for test, free, gift-card-only, Point of Sale, B2B or subscription renewal orders. See the Card Testing and Carding Attacks Defence Guide.

Metrics

Percentage of users and collaborators with two-step authentication (target 100%; passkey or security key for sensitive roles).
Number of users holding sensitive permissions or Administrator (target: the minimum, reviewed quarterly).
Active collaborators with no current engagement (target zero).
Installed apps with no named business owner or unused for 90 days (target zero).
Chargeback rate and share of high-risk orders fulfilled without review.

Hardening baseline

Week 1, owner and payments: passkey or security key on the owner account, unique owner email with its own MFA, two-step authentication on every user, payout and billing details checked and owned by finance.
Week 2, roles: replace shared logins with individual accounts; build custom roles; move sensitive permissions to named holders; enforce two-step authentication where your plan allows.
Week 3, third parties: regenerate the collaborator request code; remove finished collaborators; list every app with owner, purpose and scopes; uninstall what is not needed.
Week 4, checkout and fraud: review checkout extensions and network_access; set fraud handling rules (who reviews medium and high risk, when to use manual capture); document chargeback evidence steps.
Ongoing: quarterly access review of users, collaborators and apps; review login history monthly; rehearse the compromised account steps (below).

If the store account is compromised: Shopify's guidance is to contact Shopify Support immediately and secure the account. In practice, from a clean device: reset the owner password and two-step methods, review and remove unknown users, collaborators and apps, check payout and billing details, review recent orders, refunds, discount codes and theme edits, and regenerate the collaborator request code. See the Account Takeover Response Playbook.

Common misconfigurations

Shared owner login: staff or an agency use the owner's credentials, so there is no individual accountability, no per-person two-step authentication and no clean way to remove one person.
Administrator for everyone: Administrator includes sensitive access; giving it for convenience means any one phished staff account can change payment settings or export customers.
Never-ending agency access: collaborators kept after the project, an old request code still valid, and auto-generated roles accepted without trimming.
App sprawl: trials never uninstalled, apps holding write scopes and full order history for a marketing feature, and custom apps tied to an employee who left. The app tokens guide covers how stolen tokens are used.
Two-step authentication optional: left to each user, with SMS-era habits; nobody checks coverage.
Ignoring fraud recommendations: fulfilling high-risk orders because indicators looked mixed, rather than following the overall recommendation or using manual capture.

Framework mapping

Control area	NIST SP 800-53 Rev 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A
Unique accounts and two-step authentication	IA-2, AC-2	PR.AA-01	5.16 Identity management, 8.5 Secure authentication
Roles and sensitive permissions	AC-6	PR.AA-05	8.2 Privileged access rights
Collaborators and apps	SA-9	GV.SC-07	5.19 Information security in supplier relationships
Login and change review	AU-2	DE.CM-03	8.15 Logging

Practitioner checklist

Owner account protected with a passkey or security key and never shared.
Every user and collaborator has two-step authentication; enforced where the plan allows.
Custom roles in use; Administrator and sensitive permissions limited to named, trusted holders.
"Manage and install apps and channels" held by a small group; every app has an owner and a scope rationale.
Collaborator request code regenerated after each engagement; finished collaborators removed.
Checkout extensions reviewed, including any with network_access.
Fraud review process defined for medium and high risk orders, with manual capture where needed.
Login history and user changes reviewed monthly; full access review quarterly.
Compromised account steps written down and known to the owner and finance.

Shopify Store Security: Secure Staff Accounts, Apps and Checkout