Shopify Store Security: What Merchants Are Actually Responsible For

The line, and why it matters

Hosted platforms operate on shared responsibility. Shopify secures the infrastructure, the application, and the checkout. You secure the accounts, the people, and the connections you grant. Both halves have to hold, and only one of them is being actively worked on by a large security team on your behalf.

The reason this matters is that the half Shopify covers is the half attackers largely do not bother with. Breaking the platform is expensive and hard. Getting into an inbox is neither. So the practical security posture of your store is decided almost entirely by the half you own — which, for most small merchants, nobody has looked at since the store was built.

What Shopify covers

This is a genuine and substantial list, and it is the strongest single argument for being on a hosted platform rather than running your own store software.

• PCI compliance for the checkout. Shopify maintains PCI DSS compliance for the payment processing it operates. Card data does not sit in a database you are responsible for patching.
• Platform patching. Vulnerabilities in the store software are Shopify's problem to find and fix, and they get fixed without you scheduling anything. Anyone who has run a self-hosted store through a bad plugin vulnerability will recognise the value here.
• Infrastructure and availability. Hosting, certificates, and the capacity to absorb traffic spikes and denial-of-service attempts.

None of that is small. It removes an entire category of risk that self-hosted merchants carry permanently. The mistake is concluding that it removes all of them.

What is yours

Admin and staff accounts. Every account that can reach your store admin is a route to your money and your customer data. That includes staff, contractors, and the agency that built the store. Access should be limited to people who currently need it, at the permission level they actually need, with multi-factor authentication enforced on all of it. The most common finding in a review is an account belonging to someone who left, or a developer from a build two years ago whose access was never removed.

The email account behind the store. This is the one merchants consistently underrate. If an attacker controls the inbox tied to your Shopify account, they can reset the store password and approve the reset themselves. Securing the store admin while leaving that mailbox unprotected is a lock on a door with an open window beside it. Our business email compromise case study walks through how this plays out in practice, and our BEC guide covers the mechanics.

Third-party apps. Every app you install is granted some level of access to your store data, and that access persists until you remove it. The risk is not usually a malicious app — it is the accumulation of apps installed for a trial two years ago, still holding read access to your customer list, from a vendor whose own security you have never assessed. Reviewing and pruning installed apps is one of the highest-value hours a merchant can spend.

Your staff and their devices. A store admin logged in on a personal laptop with no protection is an access route. So is a staff member who can be talked into changing payout details by an email that appears to come from you.

Your domain and its email records. SPF, DKIM, and DMARC do two jobs: they get your order confirmations delivered rather than filtered, and they make it harder for someone to send convincing email pretending to be your store. Both matter, and this is DNS configuration rather than anything Shopify controls.

How a takeover actually unfolds

It is worth being specific, because the mental picture most merchants hold — someone breaking the website — leads them to defend the wrong thing.

The sequence usually starts with a credential: reused from another breach, or captured by a convincing phishing page. The attacker gets into the email account tied to the store. They do not immediately do anything, because the valuable part is access rather than noise. From the inbox they trigger a password reset on the store admin and approve it themselves. Now they have legitimate credentials on your store.

What follows is deliberately quiet. Payout details get changed so the next deposit lands elsewhere. The customer list is exported. An app with broad permissions gets installed. In the worst version, a script is added that captures card details at checkout while the store continues functioning normally for everyone. There is no outage, no error, nothing a merchant would notice while working. Discovery typically comes from a payment processor, a customer, or a bank — weeks later.

That pattern is why the controls that matter are unexciting ones: multi-factor authentication everywhere, alerting on new mailbox forwarding rules, periodic review of app permissions and admin access, and removing accounts the day someone leaves.

A practical checklist

None of this requires a project. Most of it is an afternoon.

• List every account with admin or staff access to the store. Remove anyone who should not still be there.
• Enforce multi-factor authentication on every remaining account — and on the email account tied to the store, first.
• Review installed apps. Remove what you no longer use. For what remains, note what data each can reach.
• Check that SPF, DKIM, and DMARC are configured for your domain.
• Set up alerting for new mailbox forwarding rules on your business email — a standard early sign of compromise.
• Confirm you have a way to verify payout or banking changes that does not rely on email.
• Write down who to call, out of hours, if the store is compromised. Deciding that during an incident wastes the hours that matter most.

Why this is our lane

Most agencies that build stores are good at building stores. Very few of them will ask who has access to your email, whether MFA is enforced on your staff accounts, or what a third-party app can read. That is not a criticism — it is a different discipline.

Brydan has been defending Las Vegas businesses against exactly these attacks since 2002, and we are a Shopify Partner that builds stores. Those two facts are the reason we do not hand the store over and walk away at launch. If you are not certain who can currently reach your store admin, that is a good enough reason to have a conversation.