Shopify security: A guide for store owners and developers
A Shopify store can keep processing orders while a third-party application changes what shoppers see before checkout. A former agency may still retain access. Customer records may continue flowing into systems nobody has reviewed since the original integration.
These are the security issues that an uptime dashboard or a successful test order may not reveal.
Shopify security involves protecting accounts, controlling applications and storefront code, securing integrations, and understanding how customer data moves through the business. It also requires clear ownership when something goes wrong.
For store owners, agencies and developers, three questions provide a useful starting point:
Who can change the store? Where does customer data go? What evidence would establish the impact of an incident?
1. What does Shopify security cover?
Shopify security covers the controls that protect a store and its connected systems from unauthorized access, unwanted changes, data exposure and disruption.
The practical scope includes:
Shopify Admin accounts, staff permissions and collaborator access.
Third-party applications and their access to store data.
Themes, app embeds and JavaScript loaded on storefronts.
Custom applications, APIs, webhooks and backend infrastructure.
Domains, email accounts and development tools.
Customer data, vendor relationships and incident response.
These areas overlap. A compromised email account can affect account recovery. An insecure internal tool can change data that an app renders on storefronts. A valid API token can be misused through an application with broken authorization.
The assessment therefore needs to follow the connections between systems, people and suppliers.
2. What is Shopify responsible for - and what remains yours?
Shopify operates the commerce platform and provides platform security controls. Merchants decide which applications to install, who receives access, what custom code to deploy and how their business uses customer data.
Shopify states that its platform is Level 1 PCI DSS compliant. That assurance has a defined scope. Your application backend, agency access, exported customer files and business procedures still require their own assessment.
Area | Primary control owner | What the merchant should establish |
Shopify platform infrastructure | Shopify | Platform responsibilities and support channels |
Staff and collaborator permissions | Merchant administrators | Who has access, why and for how long |
Third-party applications | App providers and the merchant selecting them | Permissions, data use and incident contacts |
Themes and custom storefront code | Assigned developers or agencies | Approved changes, testing and rollback |
Custom apps and backend systems | Application owners and operators | Authentication, authorization, secrets and logs |
Customer data shared with vendors | Organizations involved in processing | Purposes, roles, retention and contractual responsibilities |
Incident and recovery decisions | Designated business owners | Decision authority and reopening criteria |
Outsourcing creates dependencies worth documenting
An agency may manage a theme, code repository, domain or integration under its own accounts. That arrangement can work operationally while leaving the merchant dependent on access it does not control.
Before a supplier relationship ends, establish whether your team can retrieve the code, recover administrative access, rotate credentials and operate essential integrations.
A useful handover includes assets, documentation, ownership and confirmation that unnecessary access has been removed.
3. Where does customer data go after an order?
A customer record may pass through an order-management app, fulfillment partner, CRM, email platform, helpdesk and reporting system. Staff may also download spreadsheets and share them with external teams.
Each destination creates another location where access, retention and deletion need to be understood.
Illustrative example: a merchant connects an email marketing app and later stops using it. Removing the app may end the integration, but the team still needs to establish what happens to previously transferred contact records, exports and backups.
Build a data map around actual workflows
Processing point | Question to answer | Useful evidence |
Forms and ordering | What information is collected, and for what purpose? | Field inventory and customer-facing notices |
Third-party apps | What can the app read, write or export? | Granted permissions and vendor documentation |
Marketing and analytics | Which identifiers and events are transmitted? | Integration settings and observed requests |
Fulfillment and support | What information does each provider need? | Data-sharing scope and agreements |
Manual exports | Who downloads files, and where are they stored? | Access records and handling procedures |
Retention and deletion | What happens when the data is no longer needed? | Retention rules and deletion processes |
The map should include remote support access and subprocessors where relevant. A provider’s business address alone does not establish everywhere data may be accessed or processed.
This exercise also helps identify unnecessary collection. An integration that needs order status may not need the full customer profile.
4. Which privacy and compliance requirements may apply?
International selling creates different obligations depending on where your business operates, the individuals you serve, your processing activities and applicable thresholds.
A storefront being accessible worldwide does not, by itself, establish that every privacy law applies.
4.1. EU and UK requirements
The EU GDPR can apply to businesses established in the EU and to certain businesses outside it that offer goods or services to people in the EU or monitor their behavior.
Where applicable, identify controller and processor roles, document vendor arrangements and assess international data transfers. UK GDPR transfer requirements need separate consideration for relevant UK processing.
Remote access by an overseas organization can matter when assessing a transfer; the review should look beyond the physical location of a server.
4.2. California and other markets
The CCPA applies to businesses meeting its scope and eligibility conditions. Relevant obligations may include consumer rights, disclosures and controls over selling or sharing personal information.
Other markets have their own rules. Maintain an applicability assessment tied to the markets you actually serve.
4.3. Tracking deserves its own review
A consent banner is only useful when the technologies behind it behave as intended. Test what loads before a choice, after refusal and after withdrawal.
For example, UK guidance requires consent for storage and access technologies used for online advertising. That rule should be evaluated within its jurisdiction rather than treated as a universal standard.
Security testing and compliance assessment support each other, but a penetration test does not establish that every data-processing activity complies with applicable law.
5. Secure Shopify Admin throughout the access lifecycle
Use individual accounts, unique passwords and multifactor authentication. Protect the email accounts used for recovery, and maintain a secure recovery process.
Then review how access changes over time.
5.1. Every sensitive permission needs an owner
For staff and collaborators, record:
The person or organization receiving access.
The work requiring that permission.
The approving owner.
A review or end date.
The person responsible for offboarding.
A permission that was appropriate during a launch may remain active long after the work ends.
5.2. Offboarding should cover connected systems
Review repositories, hosting, vendor dashboards and administrative tools alongside Shopify access.
Where relevant, revoke sessions and credentials, review tokens, and transfer asset ownership. Record completion so that the business can distinguish an approved handover from an unresolved access risk.
6. Treat Shopify apps as part of your software supply chain
Installing an app extends trust to the provider’s code, infrastructure and operating practices.
The assessment should consider what the app can change and what the provider can demonstrate when an incident occurs.
Before installation or renewal, ask:
Are the requested permissions necessary?
Can the app modify storefront behavior?
Does it support custom HTML or JavaScript?
What customer data does it retain?
Who provides emergency support?
What happens to data and integrations when the service ends?
An app’s popularity does not answer these questions.
6.1. Configuration can become a route to the storefront
Some applications fetch configuration from their own servers. If that configuration is treated as executable code, a change outside the merchant’s theme repository can affect shoppers.
Shopify’s security guidance advises developers to treat runtime configuration as untrusted data.
This helps explain why examining theme files alone can miss important behavior. Read more about the reported pattern in Shopify checkout hijacking through third-party applications.
6.2. Removing an app requires follow-up
Check implementation-specific dependencies, manually inserted code and connected services. Confirm how previously shared data is handled.
Also identify which workflows will stop. A rushed removal can interrupt fulfillment, subscriptions or customer support unless those dependencies are understood.
7. Protect themes, scripts and the customer journey
Theme version comparisons can reveal changes in managed code. They may not capture configuration or scripts delivered dynamically by another service.
Combine code review with browser-based testing.
7.1. Test important purchase paths
After significant changes, test product pages, quick-buy buttons, cart drawers, cart pages and checkout entry points on relevant devices.
Observe the destination domains and compare them with the payment services and integrations your team has approved.
When investigating intermittent behavior, use fresh sessions and repeat the relevant conditions. Document what was tested so the result has a clear scope.
7.2. Successful orders do not prove the entire journey was safe
A shopper may encounter an unauthorized page and later complete a legitimate order. The final order record may not preserve that earlier interaction.
Reports of unexpected domains, duplicate requests for payment information or unfamiliar checkout screens deserve investigation even when orders continue arriving.
Shopify updated its redirect protection on October 23, 2026: it blocks destinations identified as malicious and asks for confirmation for some suspicious websites. The absence of a warning should not replace your own investigation.
8. Secure APIs, webhooks and internal tools
Custom apps and integrations require their own security controls.
Prioritize authentication, authorization, shop-level data isolation, secret management and audit logging. For Shopify webhooks delivered over HTTPS, verify the HMAC signature before trusting the payload.
Background processing also needs duplicate handling, retries and error visibility so that failures do not silently alter business records.
8.1. A valid token does not establish an authorized action
An attacker may exploit an application endpoint that triggers a legitimate backend request. In that situation, the request can use a valid token while the initiating user lacks permission.
Review the authorization checks at the point where actions are requested. Include support dashboards, migration utilities and internal tools capable of modifying storefront data.
The Smind Sections Shopify incident response and penetration testing case study illustrates why internal systems belong in the assessment scope.
8.2. October 27, 2026 update: expiring offline access tokens
Shopify has published an enforcement schedule for affected public apps using non-expiring offline access tokens.
Noncompliant apps face delisting and blocked new installations from January 1, 2027. Affected Admin API requests using those tokens will be rejected from April 1, 2027.
Custom apps and merchant-created apps are excluded from this requirement.
Merchants should ask relevant vendors about readiness. Public app developers should test token refresh, recovery and background jobs as part of their migration.
9. What should monitoring actually cover?
Start by identifying the evidence available to your team and the gaps that remain.
Signal | Potential evidence source | Limitation to understand |
Unexpected access changes | User records and available activity logs | Historical detail may be limited |
App or configuration changes | Administrative records and vendor logs | Provider-side evidence may require cooperation |
Suspicious storefront behavior | Customer reports and browser captures | Behavior may depend on session conditions |
Unusual backend activity | Application and infrastructure logs | Only covers instrumented systems |
Failed or duplicated synchronization | Webhook and job-processing records | Failures need alerting and ownership |
Shopify’s store activity log displays a maximum of 250 results and does not support direct export. It is not a complete record of every application action or shopper interaction.
Establish provider log availability and retention before an incident. Otherwise, the evidence needed to assess an event may already be unavailable.
10. What evidence do you need when something goes wrong?
Incident response needs to establish what happened, reduce continuing harm and support defensible decisions.
Capture the affected page, action, destination, timestamp and timezone. Preserve relevant screenshots, configuration, logs and browser evidence while containment proceeds.
Protect those materials: captures can contain personal information or credentials.
10.1. Define the questions before declaring closure
A useful investigation should address:
What introduced the unauthorized behavior?
When was it active?
Which stores, sessions or records may be affected?
What access or persistence could remain?
What verifies that remediation worked?
Who authorizes recovery?
Where evidence is incomplete, state that limitation. “No evidence identified within the reviewed scope” is a narrower conclusion than confirming that no exposure occurred.
10.2. Assess notification duties early
Notification requirements depend on the applicable law, organizational role and risk.
Under the EU GDPR, a controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours of awareness unless the breach is unlikely to create a risk to individuals’ rights and freedoms.
Other jurisdictions and contracts can impose different requirements. Involve the responsible privacy and legal contacts early, and document the decision process.
11. Build a 30-day Shopify security review
For an actively compromised store, prioritize incident response immediately. For a stable environment, use a phased review.
Period | Priority | Expected output |
Days 1–3 | Confirm ownership, privileged access and escalation contacts | Responsibility and access records |
Days 4–7 | Inventory apps, themes, scripts, domains and integrations | Asset and dependency inventory |
Days 8–14 | Map customer data and review vendors | Processing map and identified gaps |
Days 15–21 | Test purchase paths, APIs and internal tools | Prioritized technical findings |
Days 22–30 | Remediate, retest and rehearse response | Closure evidence and ongoing review plan |
Give each issue an owner, deadline and acceptance criterion. Record temporary controls for unresolved risks.
Repeat relevant checks when people, providers, applications or critical workflows change.
12. When should you consider Shopify penetration testing?
Penetration testing is useful when you need independent assessment of custom applications, APIs, internal tools and integrations - particularly before launch, after major changes or following containment of an incident.
Agree the assets and rules of engagement first. Merchant ownership of a store does not automatically authorize testing Shopify’s underlying infrastructure or a supplier’s systems.
A useful engagement provides evidence of exploitability, business impact, remediation guidance and agreed retesting. Its report should also identify exclusions and limitations.
For an introduction, read what penetration testing covers.
------------------
Shopify security FAQs
Is Shopify secure enough for an online store?
Shopify provides platform security controls. The overall assessment also needs to consider merchant accounts, installed applications, custom code, connected systems and data-handling practices.
Can a Shopify app create security risks?
Yes. Its permissions, infrastructure and ability to affect storefront behavior can introduce dependencies that require assessment and ongoing review.
Does uninstalling an app delete customer data?
Check the provider’s terms, technical processes and connected systems. Do not assume uninstalling resolves every retained copy or export.
Can a theme review find every malicious script?
No. Some behavior can originate from dynamically fetched configuration or other services. Combine code review with runtime testing.
Does a penetration test prove compliance?
It provides technical evidence within an agreed scope and time period. Legal applicability, contracts, privacy practices and governance require additional assessment.
Plan a Shopify security assessment with IPSIP
Prepare a list of storefronts, applications, integrations, administrative owners, data flows and recent changes.
That information helps define whether the immediate priority is incident investigation, configuration review or deeper application testing.
Explore IPSIP’s penetration testing services to discuss an assessment scope covering the systems and dependencies that matter to your business.
----------
Refferal
