Shopify security checklist: Store review and Pentest scope

1 day ago

11 min read

A useful Shopify security checklist should establish who can change your store, which applications can access customer data, and which connected systems influence the purchase journey.

It should also produce evidence. A completed checklist is more valuable when each result has an owner, a defined scope and a record that another person can review.

This guide helps merchants, agencies and development teams review accounts, applications, themes, APIs and customer data. It also explains when a deeper security assessment is appropriate and how to define a Shopify penetration testing scope.

1. Where should a Shopify security review begin?

Start by defining three things:

Scope: the stores, applications, domains, backend systems and integrations involved.
Ownership: who can provide information, approve changes and verify results.
Objective: routine review, pre-launch assurance, assessment after a major change or investigation of suspicious activity.

If shoppers are currently reaching an unrecognized payment page, or there is evidence of unauthorized access, prioritize incident response before continuing a routine review.

Background on the storefront risk is available in the analysis of Shopify checkout hijacking through third-party applications.

Distinguish configuration review from penetration testing

Activity	Main question	Expected output
Configuration and operational review	Are access, settings and responsibilities managed appropriately?	Documented control gaps and actions
Code and runtime review	Does the implementation behave as intended?	Technical evidence and areas requiring validation
Penetration testing	Can weaknesses be exploited within an authorized scope?	Validated findings, impact and remediation guidance

These activities support each other. An asset inventory improves test preparation, while penetration testing provides evidence that a basic configuration review may not produce.

Neither activity replaces ongoing management of access, suppliers and customer data.

2. Shopify security checklist

Copy this checklist into your internal working document. Replace the suggested roles with named individuals and record the date and store covered.

Use the following statuses:

Not reviewed
Verified
Action required
Insufficient evidence
Not applicable, with a reason

Mark a control as verified only when evidence supports the conclusion within the reviewed scope.

“High” indicates an initial review priority. Signs of active compromise, exposed credentials or harmful customer redirects require immediate escalation.

Area	Check	Suggested owner	Initial status	Evidence to retain	Priority
Accounts	Store ownership and current users are confirmed	Store owner	Not reviewed	Ownership and user inventory	High
Accounts	Individual accounts and secure sign-in methods are established	Administrator	Not reviewed	Configuration confirmation	High
Accounts	Staff and collaborator permissions match current responsibilities	Administrator	Not reviewed	Access review and approvals	High
Accounts	Recovery and offboarding procedures cover relevant systems	Operations lead	Not reviewed	Recovery and handover records	Scheduled
Apps	Installed and custom apps have a purpose and accountable owner	Ecommerce lead	Not reviewed	Application inventory	Scheduled
Apps	Read and write permissions are justified	Technical owner	Not reviewed	Permission review	High
Apps	Data access, recipients and provider responsibilities are understood	Privacy lead	Not reviewed	Data map and agreements	High
Apps	Uninstallation and dependency handling are planned	App owner	Not reviewed	Exit procedure	Scheduled
Storefront	Script sources, app embeds and change permissions are known	Development team	Not reviewed	Component inventory	High
Storefront	Significant code changes are approved and versioned	Development team	Not reviewed	Change records	High
Storefront	Relevant runtime configuration has been examined	Development team	Not reviewed	Runtime review results	High
Storefront	Important purchase paths are tested after changes	Technical and operations teams	Not reviewed	Test records	High
Domains and email	Domain ownership and administrative control are established	Asset owner	Not reviewed	Ownership records	High
Domains and email	Administrative accounts and recovery methods are protected	IT administrator	Not reviewed	Control confirmation	High
Domains and email	Significant DNS changes are approved and checked	IT administrator	Not reviewed	Configuration history	High
Domains and email	Renewals, recovery addresses and alert recipients are reviewed	IT administrator	Not reviewed	Renewal and contact records	Scheduled
APIs	Integrations, credential purposes and responsible owners are documented	Development team	Not reviewed	Inventory without secret values	High
APIs	Sensitive credentials are stored and used appropriately	Development team	Not reviewed	Review results	High
APIs	Authentication, authorization and shop isolation are validated	Development team	Not reviewed	Technical test evidence	High
APIs	Webhook verification, duplicate handling and failures are tested	Development team	Not reviewed	Test and processing records	High
Data and recovery	Customer data destinations and access are mapped	Privacy lead	Not reviewed	Processing map	High
Data and recovery	Applicable obligations, agreements and retention are assessed	Privacy and legal teams	Not reviewed	Assessment records	High
Data and recovery	Relevant backups and restoration procedures are tested	IT and development teams	Not reviewed	Recovery test results	Scheduled
Data and recovery	Evidence sources, incident contacts and recovery authority are defined	Operations lead	Not reviewed	Response procedures	High

Do not place passwords, active tokens, one-time codes or recovery codes in a broadly shared checklist.

3. Review Shopify Admin access and collaborator permissions

Access should be managed throughout its lifecycle: onboarding, role changes and departure.

3.1. Use individual accounts and protect recovery paths

Use separate accounts, unique passwords and secure sign-in methods, including two-step authentication.

Protect the email accounts used for recovery. Establish a recovery process that remains usable when a device is lost or the usual administrator is unavailable.

Evidence should confirm the control without exposing a person’s authentication secrets.

3.2. Compare permissions with current work

Customer service, marketing, fulfillment and development teams need different capabilities.

For sensitive permissions, establish who receives access, why it is needed, who approved it and when it should be reviewed.

Access granted for a launch can remain unnecessarily active after the project ends.

3.3. Extend offboarding beyond Shopify

Review vendor dashboards, source repositories, hosting, domain accounts and internal tools.

Removing a collaborator from Shopify does not establish that every separate account has been removed.

A handover should confirm asset ownership, transferred responsibilities and access that has been revoked.

4. Review Shopify apps before installation and renewal

Assess applications according to their purpose, permissions, data use and operational dependencies.

shopify-security-checklist-pentest — *Shopify security checlist*

For installed apps, use Settings → Apps → select the app to review available permission, activity and privacy information. Availability varies with the application and account permissions.

4.1. Match permissions to actual functionality

Ask:

Does the app need the customer information it can access?
Why does it need write access to products or orders?
Can it change storefront content or behavior?
Where does it send data?
Who can change its settings?

Read-only access can still expose sensitive information. Write access may be necessary, but its purpose and control should be understood.

Recent inactivity is a reason to investigate a permission, not sufficient evidence that it is unnecessary.

4.2. Look beyond the app’s public interface

For higher-impact applications, request proportionate information about privileged access, incident contacts, logging, data retention and independent testing.

If a provider supplies a penetration testing summary, check its date, scope, exclusions and remediation status.

A report covering the main application may not cover a separate internal tool or administrative backend.

4.3. Plan how to leave the application

Before uninstalling, identify data to retain and workflows that depend on the app.

Check the provider’s instructions for additional cleanup, manually inserted code and connected services. Review separately billed subscriptions where applicable.

Ending the Shopify installation is one part of closing the wider service relationship.

5. Review themes, scripts and the purchase journey

Storefront code affects the customer experience directly. Its sources and changes need accountable owners.

5.1. Inventory sources and approve changes

Document scripts, app embeds and external services used on important pages.

For significant changes, retain an appropriate version, identify the approver and define the rollback process.

The inventory should explain why each component exists and who can modify it.

5.2. Combine source review with runtime observation

A theme file can remain unchanged while an app fetches different configuration from another system.

Review the source of dynamically loaded content and how it is used. Shopify advises treating fetched configuration as untrusted data rather than executing it as code.

Static comparisons therefore need to be combined with observation of the running storefront.

5.3. Test relevant purchase paths

After significant changes, test product pages, quick-buy actions, cart drawers, cart pages and checkout entry points.

Record the device, session conditions, destination and payment methods involved.

A successful order only confirms the observed test. It does not establish that every earlier interaction or alternative purchase path was safe.

6. Review Shopify APIs, webhooks and connected backends

Technical owners should provide findings and evidence for these areas. Merchants should not mark implementation-level controls as verified without an appropriate review.

6.1. Authenticate requests and isolate shop data

Authenticate requests before reading or changing store data. Determine the shop from the verified authentication context rather than trusting a caller-supplied parameter.

For applications serving multiple stores, restrict data access to the authenticated shop.

A valid token does not prove that the initiating action was authorized. An insecure endpoint may trigger a legitimate backend request using valid credentials.

Include internal tools capable of altering storefront settings in the assessment.

6.2. Protect credentials according to their type

Identify credential types before deciding whether their exposure is expected or prohibited.

Sensitive access tokens and secrets must not leak through frontend bundles, public repositories or logs.

Maintain a procedure for revocation and replacement, including checks on affected background jobs and integrations.

6.3. Verify webhook deliveries and processing

For Shopify webhook deliveries over HTTPS, verify the HMAC using the original request body before trusting the payload.

Also assess duplicate handling, retries, processing errors and reconciliation.

Controls should match the actual delivery method; do not assume every event integration uses the same verification mechanism.

6.4. Account for Shopify’s October 27, 2026 token update

Shopify has published enforcement dates for affected public apps required to use expiring offline access tokens.

Noncompliant apps face delisting and blocked new installations from January 1, 2027. Affected Admin API requests using non-expiring offline tokens will be rejected from April 1, 2027.

Custom apps and merchant-created apps are excluded from this requirement.

Merchants should ask relevant providers about readiness. Public app developers should validate token refresh, recovery and dependent background processing.

7. Map customer data and assess obligations by market

Follow customer information through Shopify, applications, CRM, marketing platforms, fulfillment services, exports and support workflows.

For each destination, establish the purpose, recipient, access, retention and arrangements when the service ends.

Removing an integration does not, by itself, establish that every downstream copy has been handled.

7.1. Determine applicability before selecting compliance controls

Different markets can create different obligations.

Context	Assessment question
EU-related processing	Does GDPR apply through establishment, offering goods or services, or relevant monitoring?
UK-related processing	Which UK privacy requirements and international transfer rules apply?
California-related processing	Does the business meet CCPA scope and eligibility conditions?
Other markets	Which local laws, sector rules and contractual commitments apply?

Where GDPR applies, establish controller and processor roles based on actual activities and ensure relevant processing arrangements are documented.

For UK processing, overseas organizational access can matter when assessing a restricted transfer. A server’s location alone does not answer the transfer question.

Do not assume every vendor has the same legal role, or that one privacy configuration meets every jurisdiction’s requirements.

Security testing produces technical evidence. It does not replace a broader assessment of legal applicability, contracts, notices or data-handling practices.

8. When is Shopify penetration testing appropriate?

Penetration testing is useful when the business needs independent validation of weaknesses in assets it owns or is authorized to test.

Consider it when:

Launching a custom app or important integration.
Making significant changes to authentication, authorization or architecture.
Leaving important technical controls unverified after a review.
Providing assurance requested by a customer or partner.
Validating remaining weaknesses after incident containment.

A stale account or missing application inventory may be addressed through operational work first. A pentest should have a defined question and relevant assets.

For an introduction to the assessment process, read what penetration testing covers.

9. What should a Shopify pentest scope include?

Translate “Shopify penetration testing” into specific assets, roles and scenarios.

Scope area	Potential assessment focus	Authorization requirement
Custom web applications	Authentication, sessions, authorization and business logic	Ownership or explicit permission
APIs	Object access, function permissions, data exposure and actions	Agreed endpoints and roles
Internal tools	Privileged functions and configuration changes	Explicit inclusion
Integrations	Credentials, webhook processing and data flows	Responsibilities across parties
Custom storefront code	Rendering, script sources and relevant behavior	Agreed code and store scope
Supporting infrastructure	Relevant configuration and exposed services	Approved asset inventory

Owning a store does not automatically authorize testing Shopify’s underlying infrastructure or an app provider’s systems.

Distinguish storefront code, custom backends and platform-managed checkout components. Findings in one component should not be generalized to the whole Shopify platform.

10. Prepare for the assessment

Good preparation helps align testing effort with business risk.

Information	What to provide
Business role	Merchant, agency or app developer
Objective	Launch, periodic review, major change or post-incident assessment
Assets	Domains, applications, APIs and internal tools
Architecture	Main components and integration flows
Test access	Relevant roles and suitable test data
Boundaries	Excluded actions, timing and stop conditions
Coordination	Technical contacts and critical-finding escalation
Validation	Expected remediation and retest arrangements

Do not submit production passwords or tokens through an initial inquiry form. Agree a secure access-handover process when testing is arranged.

A test environment can reduce operational impact, but document how it differs from production. Production testing requires appropriate boundaries, coordination and authorization.

11. What should the pentest deliver?

The output should help business owners understand risk and technical teams implement remediation.

Expect clearly defined deliverables such as:

An executive summary of material risks.
Scope, methods and assessment limitations.
Findings with conditions and supporting evidence.
Affected assets and business impact.
Actionable remediation guidance.
Retest results within the agreed scope.

Distinguish a recommendation being issued from a fix being implemented and independently verified.

The Smind Sections incident response and security testing case study illustrates how investigation, application testing and remediation verification can work together.

12. What affects the cost of Shopify penetration testing?

Cost depends on the systems and testing depth, not simply the number of storefronts.

Relevant factors include:

The number of applications, endpoints and user roles.
Business logic and multi-store complexity.
Custom integrations and administrative tools.
Available architecture information and source access.
Environment preparation and testing restrictions.
Reporting and retesting requirements.

Two stores on the same platform can have very different connected environments.

Compare proposals by assets, scenarios, exclusions and deliverables rather than price alone.

13. Set a review schedule and remediation process

Timing	Suggested activity
Daily	Review customer reports, security alerts and important integration failures
Weekly	Reconcile app, theme and sensitive configuration changes
Monthly	Review access, unnecessary applications and outstanding actions
Risk-based cycle	Reassess providers, recovery and custom systems
After major changes	Validate affected components and dependencies
During an incident	Contain impact, preserve evidence and investigate promptly

This is a suggested operating cadence, not a universal requirement.

For each gap, record an accountable person, deadline, temporary control and closure criterion. Keep “Insufficient evidence” visible until the uncertainty is addressed.

A high checklist completion percentage is not a security guarantee. One exposed credential or unaddressed authorization weakness may outweigh many completed administrative checks.

-------------------

Frequently asked questions

Can a nontechnical store owner use this checklist?

Yes. Start with ownership, user access, app inventory and responsibilities. Assign code, API and backend checks to qualified technical owners and request evidence.

Do App Store applications still need review?

Yes. Assess their permissions, data handling and suitability for your actual workflows.

Is vulnerability scanning enough?

Scanning can identify some issues. Authorization, business logic and complex interactions may require deeper manual validation.

Does passing a pentest guarantee the store is secure?

No. Results apply to an agreed scope and time. Later changes to code, access, configuration or suppliers can introduce new risks.

Does every Shopify store need the same assessment?

No. Scope should reflect the assets, data, customizations, business impact and applicable obligations.

Can operational review and penetration testing be combined?

Yes, provided responsibilities and deliverables remain clear. An initial review can identify which assets and scenarios require deeper testing.

Plan a Shopify security assessment with IPSIP

Start with the checklist and a list of unresolved technical questions. Include your role, authorized assets, connected systems and assessment objectives.

Explore IPSIP’s penetration testing services to discuss scope, evidence-based reporting, remediation guidance and agreed retesting.

Pentest services | OWASP Penetration Testing | IPSIP Vietnam

The aim is to examine the relevant systems and produce findings your team can use to reduce practical risk.

This article is for general informational purposes only. It does not replace legal advice or a security assessment tailored to a specific environment. Verify your actual configuration, current requirements and testing authorization before applying the guidance.

-------------

References