Salesforce B2C Commerce Security: Lock Down Account Manager, Business Manager and Storefront Scripts

A Salesforce B2C Commerce realm runs storefronts that take payments and hold shopper accounts, so an over-privileged Business Manager user, a broadly scoped API client or a tampered storefront script can reach orders, customer data and the checkout page itself. Salesforce secures the platform and API endpoints; the customer owns user access, API client scopes, the code and cartridges deployed to the realm, and the browser-side protections on each storefront. This guide covers how Account Manager and Business Manager handle identity, how to scope OCAPI and SCAPI clients and WebDAV access, how to manage cartridges, third-party libraries and secrets, how to configure Content Security Policy and Subresource Integrity against client-side skimming, and how to use the security log. It is written for B2C Commerce administrators, storefront developers and the security teams who review them.

This is an independent guide from NHI Mgmt Group, based on Salesforce's public B2C Commerce Security Guide and developer documentation as of November 2026. It is not sponsored or reviewed by Salesforce. Product features change, so confirm settings against Salesforce's current documentation.

Key takeaways

• Use unified authentication for every administrator. Salesforce advises administrators to sign in through Account Manager, where MFA is part of the login experience, rather than with local Business Manager accounts.
• API clients start with nothing: keep it that way. New OCAPI clients are deny-by-default, and SCAPI tokens carry only Allowed Scopes, so create one client per integration with only the rules and scopes it needs.
• Code upload is the crown jewel. Salesforce calls uploading code a sensitive operation because an untrusted upload can expose most of the realm, so restrict WebDAV cartridge access and review every cartridge.
• CSP is the customer's job. Salesforce states that Content Security Policy configuration is the customer's responsibility; pair it with Subresource Integrity hashes on remotely hosted scripts.
• Download the security log. Business Manager logins, WebDAV access and role changes are logged under Securitylogs with a [DW-SEC] prefix and deleted after 90 days, so ship them to your SIEM.

How identity and access work in Salesforce B2C Commerce

B2C Commerce separates the identity of a person or client (Account Manager) from what it may do on each instance (Business Manager roles and API rules). Shoppers are a third population, authenticated by the storefront.

Account Manager and MFA

Account Manager gives users one login for every Business Manager instance in the organisation. Salesforce Trailhead material states that MFA is part of the B2C Commerce login experience and cannot be turned off. Supported methods, depending on organisation settings, are Salesforce Authenticator push (version 3 or later, on a device secured with PIN or biometrics), FIDO U2F or WebAuthn security keys, and TOTP authenticator apps that follow RFC 6238. Salesforce recommends registering at least two methods. Accounts can be local or linked to Salesforce Identity, with account administrators setting linking to allow, enforce or disable. NHI Mgmt Group recommends security keys for anyone holding the Business Manager Administrator role. See the MFA Guide.

Shared responsibility

Salesforce's security guide describes security as a partnership: Salesforce manages the platform, and the customer manages user access, network restrictions, code, configuration and data handling. For headless builds the customer also secures its own presentation and back-end-for-frontend layers, while Salesforce secures the API endpoints. Map these duties to your PCI DSS responsibilities with the PCI DSS for Service Providers and Responsibility Matrix Guide.

Admin roles and privileged access

• Business Manager Administrator: the Account Manager role that grants administrator access to Business Manager on the instances in its scope. Assign it per instance and keep the list short; most staff need Business Manager User with custom Business Manager roles.
• Account administrators: manage users in their primary organisation, restore access when a user loses all MFA methods and set Salesforce Identity linking. Treat them as identity administrators.
• Custom Business Manager roles: Business Manager uses role-based access control, with permissions per module and site. Build roles by job (merchandising, content, customer service, order management) and grant sensitive modules such as payment methods, customer data and code management only where needed.
• Role changes are logged: the security log records all role and permission changes, which gives you an audit trail for privileged access reviews.
• Development access: the Access_Protected_Storefront functional permission limits a protected storefront to Business Manager users during development; remove it from users who no longer work on the site.

Network restrictions for Business Manager

Business Manager supports an IP allowlist and blocklist, which Salesforce describes as a way to lock out attackers who obtained valid credentials. If an address is on both lists it is denied. Allowlist corporate egress and VPN ranges for production Business Manager, and keep a documented process for changes. See the Privileged Access Management Guide.

Integrations, API tokens and service accounts

OCAPI and SCAPI clients

• Client secrets are non-human credentials: store them in your secrets manager, record an owner and a rotation date, and remove clients when an integration is retired. See the API Key Management Guide.
• Headless output encoding: SCAPI returns stored data without HTML encoding because it is a context-neutral JSON API, so the custom storefront must encode for the output context.
• Rate limits and CORS: SCAPI applies rate limiting, and Salesforce documents CORS settings; configure CORS to your own storefront origins.

Secrets inside the realm

Salesforce's Secret Storage guidance lists three places for secrets: service credentials (managed in Business Manager with a service, profile and credential configuration, and read in code through the read-only dw.svc.ServiceCredential object), private keys and certificates (managed through a Business Manager wizard and referenced with CertificateRef and KeyRef), and custom object attributes of type PASSWORD. Salesforce states that service credentials must never be returned to a storefront request or written to logs. Keep API keys for payment, tax and fraud services in service credentials, never in cartridge code or site preferences of type string.

Cartridges and third-party code

• Code upload: restrict who can write to the cartridges folder over WebDAV and deploy through a pipeline with an API client scoped to code upload.
• Libraries: Salesforce advises keeping a record of every library the storefront needs, removing unused ones, sourcing them from trusted locations, pinning exact versions and upgrading to supported versions promptly. SiteGenesis and SFRA both include third-party libraries.
• Customisations in separate cartridges: Salesforce's AppExchange security requirements ask solution providers to direct customers to put customisations in separate cartridges, to serve client-side scripts statically from the cartridge, to protect state-changing controllers with CSRF tokens, to escape user content and to follow least privilege for OCAPI and SCAPI permissions. Apply the same bar to your own cartridges and to any partner cartridge before installation.

See the Software Supply Chain Security Guide.

Logging and detection

The security log

B2C Commerce writes security events to the WebDAV Securitylogs folder (https://<instance>/on/demandware.servlet/webdav/Sites/Securitylogs), with entries prefixed [DW-SEC] that include user, IP address and action. Logged events include Business Manager logins and re-logins, WebDAV operations such as MKCOL, PUT, MOVE and GET, Folder Browser file access, all role and permission changes, and Salesforce employee access to sensitive areas such as orders_paymethods, customers_gdpr and sourcecode. Salesforce deletes security log files after 90 days, and customers cannot turn security logging off. File access through Import and Export and through the script API sits outside this log, so cover those paths with job monitoring and code review.

• Collect: a dedicated WebDAV client with read access to Securitylogs only, pulling files to your SIEM daily.
• Secure logging in code: Salesforce asks developers to redact sensitive data in B2C Commerce log files; never log card data, passwords, tokens or service credentials.

Detection ideas

• Business Manager logins from addresses outside the allowlist ranges you expect, or from new countries.
• PUT or MOVE operations in cartridge folders outside a deployment window.
• Role or permission changes that add payment method, customer or code modules.
• New OCAPI rules or SCAPI scopes granting write access.
• CSP violation reports pointing at unknown script hosts on checkout pages. See the Client-Side Security Guide.

Metrics that show it is working

1. Share of Business Manager users on unified authentication with phishing-resistant MFA.
2. Number of Business Manager Administrator assignments per production instance.
3. API clients with an owner, minimal scopes and a secret rotated within your policy.
4. Share of remotely hosted storefront scripts loaded with an integrity hash.
5. Days of security log retained in the SIEM (target: at least a year, beyond the platform's 90 days).

Hardening baseline

Storefront skimming defences

Payment page script tampering is the attack customers can prevent most directly on B2C Commerce. Salesforce's CSP guidance says your policy must allow Salesforce analytics scripts, the inline scripts the storefront needs and Einstein scripts, then troubleshoot violations from the browser console. A practical order, in NHI Mgmt Group's view:

1. Inventory scripts: list every script on checkout and account pages, its source and its owner. PCI DSS v4.0 requirements 6.4.3 and 11.6.1 expect this for payment pages; see the PCI DSS for E-commerce Payment Page Scripts Guide.
2. Self-host where possible: serve scripts statically from a cartridge so changes go through code review and deployment.
3. Add integrity: pass an integrity hash as the second argument to SFRA's addJs and addCss for any remote resource that must stay remote.
4. Deploy CSP: start on a staging instance, fix violations, then enable on production per site. See the Content Security Policy Guide.
5. Monitor: alert on new script sources and on cartridge changes outside deployment windows.
6. Roll back: keep the previous policy version so a blocking error on checkout can be reverted in one change.

Decision guidance

• SFRA storefront or headless: with SFRA, controller CSRF protection and template encoding live in your cartridges; with a headless storefront, your own front end must encode SCAPI data and protect its back end, and SCAPI scopes become the main authorisation control.
• Small merchants with a single site and partner-built cartridges should focus on unified authentication, a short administrator list, CSP and a contractual requirement that the partner meets Salesforce's secure coding requirements.
• Multi-brand realms should standardise roles, OCAPI rules and CSP per site through export and import, so every instance matches the reviewed baseline.

Common misconfigurations

• Local administrator accounts: administrators sign in with local Business Manager credentials instead of unified authentication, outside the Account Manager MFA flow.
• One API client for everything: a single client with broad OCAPI Data API rules and .rw scopes serves the ERP, the PIM and a marketing tool.
• Secrets in code: payment or tax API keys hard-coded in a cartridge or site preference instead of service credentials.
• Unpinned libraries and remote scripts: storefront pages load third-party JavaScript from external hosts with no integrity hash and no owner.
• No CSP, or a permissive one: CSP left unconfigured or written with wildcards to stop violations, so injected scripts run on checkout.
• Security log left on the platform: logs age out after 90 days before anyone reads them.

Framework mapping

Practitioner checklist

• All administrators use unified authentication through Account Manager with at least two MFA methods, preferably security keys.
• Business Manager Administrator is assigned per instance to a short, reviewed list.
• Production Business Manager has an IP allowlist.
• Every OCAPI and SCAPI client has one purpose, an owner, minimal rules or scopes and a managed secret.
• WebDAV access to cartridges is limited to the deployment client.
• Integration secrets live in service credentials, KeyRef, CertificateRef or PASSWORD attributes, never in code or logs.
• Third-party libraries are inventoried and pinned, and remote scripts carry integrity hashes.
• Content Security Policy is configured and tested on every storefront, with violations monitored.
• Security logs are pulled to the SIEM daily and kept beyond the platform's 90 days.
• Partner cartridges are reviewed against Salesforce's B2C Commerce secure coding requirements before installation.

Standards and references

• Salesforce: B2C Commerce Security Guide
• Salesforce: Security Event Auditing
• Salesforce: OCAPI Client Authentication and Authorization
• Salesforce Developers: B2C Commerce headless security
• Salesforce: Secret Storage
• Salesforce: Supply Chain Security
• Salesforce: Content Security Policy Configuration
• Salesforce Developers: Secure Your B2C Commerce Solution

Related NHI Mgmt Group resources: Client-Side Security Guide · PCI DSS for E-commerce Payment Page Scripts Guide · Ecommerce Store Security Checklist · Card Testing and Carding Attacks Defence Guide · Salesforce Security Guide