Protect administrative control of the store
Use individual staff accounts, strong authentication, and the narrowest role that supports each job. Protect the primary account, email, domain registrar, payment services, and connected marketplaces with multi-factor authentication. Review accounts promptly when an employee, developer, agency, or supplier relationship changes.
Document who may create API accounts, install apps, change checkout or payment settings, publish themes, export customers, and modify domains. Avoid using one privileged credential across development, staging, automation, and production.
Control API accounts and custom apps
Create API credentials for a specific integration and grant only the scopes it requires. Store client secrets and access tokens in protected server-side configuration, never in storefront JavaScript, public repositories, support tickets, or logs. Rotate credentials after personnel changes, suspected exposure, or decommissioning.
For single-click and custom apps, validate signed payloads and callback context using the current BigCommerce developer documentation. Tie the installed store to an internal tenant record and verify authorization on every subsequent request. Do not trust a store hash, account identifier, or return URL merely because it appears in a browser request.
Validate webhook signatures where supported, restrict request sizes, and make handlers idempotent. Queue substantial work so the receiver can acknowledge promptly. Expect retries, duplicates, and out-of-order events, and log event identifiers without recording unnecessary customer data.
Review storefront and theme code
Version theme code and use a reviewed publication process with a rollback point. Escape dynamic content for the correct HTML, attribute, URL, CSS, or JavaScript context. Review helpers that intentionally output raw markup and sanitize merchant- or customer-controlled rich content.
Inventory scripts loaded through themes, script managers, apps, analytics, chat, reviews, advertising, and tag management. For each script, record the owner, required pages, data received, allowed origins, consent category, and removal procedure. Remove abandoned integrations rather than leaving dormant remote code in the storefront.
Set suitable security headers at the edge where the platform and storefront architecture allow them. Test any Content Security Policy in report-only mode first because payment, analytics, app, and image origins need deliberate treatment.
Protect customer, order, and payment workflows
Keep cardholder data inside supported platform and payment-provider flows. Custom forms, logs, analytics, and support tools should not capture sensitive payment fields. Restrict customer and order exports, set retention expectations, and protect data after it enters ERP, CRM, fulfilment, tax, email, or analytics systems.
Custom middleware must validate input, enforce object-level permissions, and protect state changes from CSRF or replay according to its authentication design. Apply rate limits to login, account recovery, promotions, inventory checks, search, and other abuse-prone workflows.
Test business logic as well as technical injection: price and currency changes, coupon reuse, inventory races, order ownership, refund permissions, gift cards, and administrative actions can all create material risk.
Monitor and recover
Alert on privileged-user changes, new API accounts, app installations, theme publication, payment changes, unusual exports, and repeated authentication failures. Maintain contacts and revocation steps for every critical vendor.
Keep version-controlled theme code and document which product, customer, and order data can be restored or reconstructed. Test rollback of storefront code and recovery of connected services. An export alone may not capture app settings, external databases, scripts, or operational workflow.
BigCommerce security review checklist
- Staff, email, domain, and payment access use MFA and least privilege.
- Each app and API account has an owner, narrow scopes, and a rotation process.
- Signed callbacks and webhooks are verified using current platform guidance.
- Theme code, raw output, URLs, and third-party scripts receive security review.
- Customer, order, payment, export, and connected-system data flows are documented.
- Business-logic abuse cases are included in application testing.
- Monitoring, revocation, rollback, and continuity procedures have named owners.
