BigCommerce Security: The SaaS Commerce Split

BigCommerce sits in the same family as Shopify: a managed SaaS commerce platform where the vendor operates the infrastructure, patches the application, and maintains its own PCI certification for the checkout. The security profile follows from that architecture and is broadly similar.

Because the shape is the same, the useful thing is not to repeat the general SaaS case but to be specific about what BigCommerce merchants actually need to watch.

What the platform handles

Server and network security, application patching, TLS, platform-level DDoS and WAF protection, and a PCI DSS certified checkout environment. None of these is your operational responsibility and none of them can be neglected by you into a vulnerability. As with any SaaS platform, this removes the failure mode that causes most mass compromises of self-hosted stores.

What remains yours

User accounts and permissions. BigCommerce offers granular user roles. The common failure is not the absence of controls but the habit of granting broad access because it is quicker, then never revisiting it. Enforce 2FA, scope roles to the job, and remove accounts when engagements end. See access control and 2FA.

Apps and API accounts. Marketplace apps and any custom integrations you build both hold API credentials with defined scopes. Store API accounts in particular are easy to create for a one-off integration and easy to forget, and a live credential with write access to orders and customers is a standing risk. Inventory them, scope them narrowly, and revoke what is not in active use. See the plugin and app supply chain.

Theme and storefront scripts. Stencil themes are code, and script tags added through the control panel or a tag manager execute on your storefront. This is where skimming gets introduced on SaaS stores when it happens at all, since the platform itself is not the weak point. Keep a list of every third-party script on the storefront and why it is there.

Headless deployments. BigCommerce is frequently run headless, with the storefront built separately and the platform used through its APIs. That is a materially different security posture: you take on the front end, its dependencies and its build pipeline, while keeping the platform's commerce layer. If that describes your setup, read headless and custom build security alongside this page, because the front end is then yours in full.

Payments and PCI

Using the platform's certified checkout substantially reduces merchant PCI scope, which is one of the main reasons to be on it. Scope reduction is not scope elimination: obligations relating to the scripts running on payment pages, and to any handling of card details outside the checkout such as over the phone, still apply to the merchant. See PCI DSS 4.0 requirements.

The practical checklist

Enforce 2FA on every control panel user. Review users and API accounts quarterly and after any staff or agency change. Audit installed apps and their scopes. Keep an inventory of storefront scripts. Confirm what the platform does and does not back up for you, and keep your own export of product and customer data. And secure the email account and domain registrar behind the store, since account recovery runs through them. See backup and recovery.

For the comparison across platforms, see website security by platform.