A BigCommerce control panel login or store-level API token can change prices, export customers, install apps and add scripts to the checkout, so staff permissions, API accounts and Script Manager deserve the same care as payment credentials. BigCommerce runs the platform as a PCI DSS compliant service provider, and the merchant controls who can sign in, which apps and API accounts exist, what code runs on the storefront and how shopper accounts are protected. This guide covers those customer-side settings: user roles and high-risk permissions, two-factor authentication, store-level, app-level and account-level API accounts, Script Manager and integrity hashes, storefront security headers, bot protection and Store Logs. It is written for ecommerce managers, agency developers and security teams responsible for a BigCommerce store.
This is an independent guide from NHI Mgmt Group, based on BigCommerce's public documentation as of November 2026. It is not sponsored or reviewed by BigCommerce. Product features change, so confirm settings against BigCommerce's current documentation.
Key takeaways
- Keep high-risk permissions with very few people. Only the Store Owner can grant the permissions to create, list and delete store-level API accounts and to install or launch apps, and 2FA must be on for the Store Owner and every user who holds them.
- Treat API tokens as permanent until deleted. BigCommerce access tokens do not expire on a timer, so scope each API account to the minimum and delete accounts you no longer use.
- Put integrity hashes on every payment page script. Script Manager accepts up to five SRI hashes per script, and BigCommerce states checkout scripts need at least one to meet PCI DSS 4.0 requirement 6.4.3.
- Turn on the storefront headers. Security and Privacy settings include HSTS, a custom Content Security Policy header and X-Frame-Options; test HSTS with the five-minute max-age first.
- Read Store Logs weekly. The Staff Action Log records user, IP address and action for control panel changes, and entries are kept for 365 days.
How identity and access work in BigCommerce
Staff sign in to the control panel with a BigCommerce account and a second factor. Automated access uses API accounts with OAuth scopes. Shoppers have storefront accounts governed by the Security and Privacy settings. Security is a shared responsibility: BigCommerce describes itself as a PCI DSS compliant service provider validated at Level 1, and its PCI Compliance article states that the ultimate responsibility for PCI compliance lies with the merchant, depending on store architecture and integrations.
| Identity | How it authenticates | Customer control |
|---|---|---|
| Store Owner | Control panel login with 2FA | Financial owner of the account; grants high-risk permissions |
| Staff users | Control panel login; authenticator app (TOTP) or email verification | Role and individual permissions under Account Settings, Users |
| Store-level API accounts | Static access token in the X-Auth-Token header | Scopes fixed at creation; delete to revoke |
| Apps (app-level API accounts) | Per-store access token issued at install through a grant code flow | Install only reviewed apps; uninstall to remove access |
| Account-level API accounts | Token for the GraphQL Account API across all stores under the parent account | Tightly held; delete from the account control panel |
| Shoppers | Storefront account password | Shopper Password Complexity, Failed Login Lockout, reCAPTCHA |
Two-factor authentication
Each user sets up 2FA under My Profile, Two-Factor Authentication, using any TOTP authenticator app (BigCommerce mentions Twilio Authy) or email verification. Each user manages their own authenticator method, so ask staff to enrol an authenticator app and check it during access reviews. If a user loses their device, BigCommerce Support can disable 2FA only for the owner of that user account. As of November 2026 the BigCommerce support articles we reviewed describe control panel sign-in with password and 2FA; if you need IdP-based sign-in, confirm the current options with BigCommerce.
The Control Panel Inactivity Timeout (Settings, Security and Privacy) ranges from 20 minutes to 2 hours and always applies, with a five-minute warning. Our recommendation: 20 to 30 minutes for staff with payment or settings permissions.
Admin roles and privileged access
Permissions are grouped into default user roles that build on each other: Sales Staff, Sales Manager, Store Administrator, Store Owner and Custom. Pick a role, then switch individual permissions on or off under Account Settings, Users, Action, Edit. Some permissions depend on others, for example Edit Orders needs Manage Orders.
| Permission | Why it is sensitive | Our guidance |
|---|---|---|
| High-risk: create, list and delete store-level API accounts | Creates long-lived tokens with store data access | Store Owner plus one named deputy, 2FA mandatory |
| High-risk: install, uninstall and launch apps | Apps receive their own tokens and can add storefront scripts | Platform owner only; change ticket per install |
| Use Script Manager | Adds code to storefront, checkout and order confirmation | Developers and agency staff only, time-limited where possible |
| Manage Payments (needs Manage Settings) | Changes payment methods and gateway settings | Finance lead and platform owner |
| Export Customers (needs Manage Customers) | Bulk export of personal data | Named marketing and data roles only |
| Manage Users, Add Users, Edit Users, Delete Users | Grants every other permission | Store Owner and one System Admin |
| Store Logs | Visibility of staff actions and system events | Grant to security reviewers |
- High-risk rules: Only the Store Owner grants high-risk permissions, 2FA must be on for the Store Owner and the grantee, and the grantee needs all other user permissions, so high-risk users are effectively full administrators. Keep the count to two or three.
- Agency access: Give agencies their own named users rather than shared logins, remove Script Manager and high-risk permissions when a project ends and check the Staff Action Log for their last activity.
- Joiners and leavers: Delete users the day they leave; review the Users list monthly against HR and agency contracts.
Integrations, API tokens and service accounts
BigCommerce has three kinds of API account. Store-level accounts are created by merchants under Settings, Store-level API accounts; their token is static and their scopes cannot be changed after creation. App-level accounts are created by developers in the Developer Portal, and each installing store gets its own token. Account-level accounts serve the GraphQL Account API and reach every store under the parent account. Requests pass the token in the X-Auth-Token header; X-Auth-Client is deprecated and legacy basic authentication is not available to new stores. For general token practice, see the API Key Management Guide.
| Resource | Read-only scope | Modify scope | Typical least-privilege use |
|---|---|---|---|
| Products | store_v2_products_read_only | store_v2_products | Feed exports read-only; PIM sync modify |
| Orders | store_v2_orders_read_only | store_v2_orders | ERP and fulfilment; reporting read-only |
| Customers | store_v2_customers_read_only | store_v2_customers | CRM sync only; personal data scope |
| Carts | store_cart_read_only | store_cart | Headless storefronts |
| Store Inventory | store_inventory_read_only | store_inventory | Warehouse systems |
| Themes | store_themes_read_only | store_themes_manage | CI theme deploys only |
- Token lifetime: BigCommerce documents that access tokens stay valid until revoked (account-level tokens while the account is active), so plan rotation yourself. To revoke, delete deleting the store-level API account (irreversible, and its webhooks do not persist) or uninstalling the app. Plan replacement before you delete.
- Client secret: The client ID and client secret never change. Never send the secret in plain text or unencrypted payloads; store it and the token in a secrets manager. See the Secrets Management Guide.
- One account per integration: Create a separate store-level API account for each system so you can delete one without breaking others, and name it after the system and owner.
- Rotation (ours): Because tokens are static, rotate on a schedule by creating a new API account with the same scopes, switching the integration, then deleting the old account. We suggest yearly, and at once when a holder leaves or a token is exposed. If a token leaks, follow the Work SaaS API tokens response steps.
- Apps: App tokens refresh only when the store owner's email or the app's scopes change. Review installed apps each quarter and uninstall unused ones. See the SaaS and OAuth App Governance Guide.
Storefront scripts, checkout and fraud controls
Script Manager (Storefront, Script Manager, or Channel Manager on Multi-Storefront) holds third-party scripts created by apps, which are read-only, and user-created scripts. Each script has a placement (header or footer), a location (Storefront pages, Checkout, Order Confirmation or All pages) and a consent category (Essential, Analytics, Functional or Targeting/Advertising; uncategorised scripts default to Essential). Checkout-location scripts run only with Optimized One-Page Checkout.
| Control | Setting or field | Our baseline |
|---|---|---|
| Subresource integrity | Up to 5 SRI hashes per script (SHA-256, SHA-384, SHA-512), strongest first | At least one hash on every script that runs on checkout or My Account with stored cards |
| Script location | Storefront, Checkout, Order Confirmation, All pages | Never All pages for marketing tags; keep checkout to payment and fraud scripts |
| Consent category | Essential, Analytics, Functional, Targeting/Advertising | Categorise every script; do not leave tags as Essential by default |
| Content Security Policy | Default header or Specify my own CSP header (1,000 characters) | Custom CSP listing the script hosts you approve |
| HSTS | Max-age five minutes, one year or zero; subdomains; preload | Test at five minutes, then one year |
| X-Frame-Options | Deny, Same Origin, Allow from URL | Same Origin unless you embed the store |
- Payment page scripts: BigCommerce states that scripts customising payment pages need at least one integrity hash to meet PCI DSS 4.0 requirement 6.4.3, and that payment pages include checkout and My Account where stored cards are accepted. When a provider updates a script the old hash stops matching and the browser blocks it, so get the new hash before the provider ships. Keep an inventory of each payment page script with its business justification. See the Client-Side Security Guide and the Content Security Policy Guide.
- API-created scripts: An API account can see and change only scripts it created, while control panel users can see and delete all scripts. Associating scripts with checkout needs the Modify Checkout Content scope; grant it only to the payment or fraud integration that needs it.
- Bot and fraud controls: Enable reCAPTCHA on storefront covers contact forms, product reviews, account sign-up and password reset; checkout reCAPTCHA is configured separately under General Checkout Settings. Set Failed Login Lockout (up to 3600 seconds) and Shopper Password Complexity, and force a reset at next login after raising complexity. For card testing, combine checkout reCAPTCHA with the fraud rules in your payment gateway and a reviewed fraud app. See the Card Testing and Carding Attacks Defence Guide.
- Headless and SDK stores: When BigCommerce is used only as a backend, or with the Checkout and Payments SDKs, the merchant carries PCI scope for the storefront. Never store sensitive authentication data after authorisation.
Logging and detection
Store Logs (Settings, Store logs) has a System Log for storefront events such as orders, payment transactions and shipping quotes, and a Staff Action Log for control panel changes such as template file updates, product imports, payment method changes and page edits. Staff entries show user, IP address, action and time, but not the field that changed. Entries are kept for 365 days and need the Store Logs permission to view. Script Manager create, update and delete actions also raise control panel notifications for 14 days and are written to Store Logs.
| What to watch | Where | Response |
|---|---|---|
| Template file or script changes | Staff Action Log, Script Manager notifications | Confirm a change ticket; diff the theme |
| Payment method changes | Staff Action Log | Call the finance owner to confirm |
| New users or permission edits | Users list, Staff Action Log | Check against the access request |
| Staff actions from unfamiliar IP addresses | Staff Action Log | Reset password and 2FA for that user |
| Spikes in failed payment transactions | System Log, gateway dashboard | Raise checkout reCAPTCHA and gateway rules |
Metrics: users holding high-risk permissions; percentage of staff with an authenticator app enrolled; store-level API accounts without a named owner; payment page scripts without an SRI hash; days since the last Store Logs review; failed payment ratio per day.
Hardening baseline
- Inventory: Export the Users list, list store-level and account-level API accounts, installed apps and every Script Manager entry with its location.
- Identity: Enrol every user in authenticator-app 2FA, set the Control Panel Inactivity Timeout, and reduce high-risk holders to two or three.
- Permissions: Move staff to the lowest default role, then add individual permissions; remove Script Manager and Export Customers where not needed.
- API accounts: Replace broad accounts with one per integration and read-only scopes where possible; delete unused accounts after confirming nothing calls them.
- Scripts: Add SRI hashes to payment page scripts, set consent categories, move marketing tags off checkout.
- Headers: Turn on HSTS at five minutes, then one year; set X-Frame-Options and a custom CSP in report-and-adjust cycles on a staging channel first.
- Shoppers: Enable storefront and checkout reCAPTCHA, set Failed Login Lockout and password complexity.
- Rollback: Record each setting before change. Scripts and headers can be reverted in the control panel; deleting an API account cannot be undone, so switch integrations first.
Small merchants should focus on 2FA, minimal high-risk users and fewer apps. Larger or multi-storefront estates add per-channel script reviews, account-level API governance and a written PCI responsibility split with each agency and app provider.
Common misconfigurations
- Shared Store Owner login: Several people use one account, so the Staff Action Log cannot tell them apart. Give each person a named user.
- One API account for everything: A single token with modify scopes for products, orders and customers sits in several systems. Split it and use read-only scopes.
- Payment page scripts with no hash: Tags added by marketing run on checkout. Add SRI or move them to Storefront pages.
- Agency users left in place: Former agencies keep Script Manager or high-risk permissions. Remove at project close.
- HSTS preload without testing: Preload needs a 12-month max-age and subdomains; test subdomains first.
- Removing app scripts by hand: BigCommerce advises not to remove an app's scripts before uninstalling the app; uninstall the app and confirm its scripts are gone.
Framework mapping
| BigCommerce control | NIST SP 800-53 Rev 5 |
|---|---|
| Named users, roles, high-risk permissions | AC-2, AC-6 |
| 2FA and inactivity timeout | IA-2, AC-12 |
| API account scopes and deletion | AC-6, IA-5 |
| Script Manager SRI and inventory | SI-7, CM-7 |
| Apps and agencies | SA-9, SR-3 |
| Store Logs review | AU-2, AU-6 |
Practitioner checklist
- Give every person a named user with authenticator-app 2FA and set a short control panel inactivity timeout.
- Limit high-risk permissions to two or three people and review them monthly.
- Assign the lowest default role and add only the individual permissions each job needs.
- Create one store-level API account per integration with read-only scopes where possible.
- Store client secrets and tokens in a secrets manager and rotate by replacement on a schedule.
- Review installed apps quarterly and uninstall unused ones.
- Add SRI hashes to every payment page script and categorise all scripts for consent.
- Turn on HSTS, X-Frame-Options and a custom CSP after testing.
- Enable storefront and checkout reCAPTCHA and set Failed Login Lockout.
- Review the Staff Action Log weekly for script, payment and user changes.
Standards and references
- BigCommerce: User Permissions
- BigCommerce: Setting Up 2FA
- BigCommerce: API Accounts
- BigCommerce: Using Script Manager
- BigCommerce: Scripts API
- BigCommerce: Security and Privacy Settings
- BigCommerce: Using Store Logs
- BigCommerce: PCI Compliance
Related NHI Mgmt Group resources: Cybersecurity for Retail and Ecommerce Guide · Account Takeover Prevention Guide · Bot Management Guide