Security
Ensuring data privacy and trusted access to ecommerce systems is a critical part of the B2C Commerce platform. All interactions with the Salesforce Commerce API must be fully authenticated and authorized.
B2C Commerce provides authentication, authorization, and availability features for headless commerce.
Authentication is about validating identity to make sure that the client (for example, a PWA Kit storefront) is who it says it is. An administrator provisions an API client with a secret (think of it like a password). The client uses the secret to request an access token. The API gateway authenticates the client’s identity based on the access token.
Authorization is about validating access to a particular resource and making sure that the client has permission to perform certain tasks. An administrator provisions an API client with scopes that assign permissions to the client. The API client specifies a set of scopes when requesting an access token. The API gateway performs authorization on the basis of the access token. For more information, see Authorization.
Availability ensures that a service remains up and running. Availability is implemented for headless commerce using DoS protection and API Rate limiting. For more information, see Rate Limits.
As a B2C Commerce customer, you’re responsible for providing security for your custom head, including both the presentation and BFF layers, since the custom head runs on your infrastructure and application stack. Make sure that you’re willing and able to take on this responsibility. Building, hosting, and maintaining high-traffic public-facing applications can be extremely challenging.
Salesforce is responsible for providing security for the API endpoints exposed to your custom head and the B2C Commerce platform on which your commerce resources are hosted.
Availability ensures that a service remains up and running. Availability is implemented for headless commerce using DoS protection.
Follow all general good security principles when developing for headless commerce, for example, defense-in-depth and secure defaults. Implement maximum protection for your sites against security threats using the best practices described in General Security Best Practices.
Use secure design and coding practices during implementation. We recommend reviewing the resources provided by the Open Web Application Security Project (OWASP). OWASP is an online community that provides articles, methodologies, documentation, tools, and technologies for web application security.
Follow B2C security best practices when developing your headless commerce architecture.
In addition to implementing the B2C security best practices described here, you’re also responsible for implementing security on your own front-end infrastructure as part of the shared responsibility model.
Follow the principle of least privilege to give API clients, users, applications, systems, and other components only the minimum privilege level they need to do their jobs. Implement the least privilege principle when you provision an API client in Account Manager. Also apply least privilege when an API client requests a JWT access token from Account Manager. When a client calls an API, the API gateway performs authorization on the basis of the access token.
As described in Authorization, the B2C Commerce headless model uses OAuth scopes to define permissions for API Clients. As part of the API Client provisioning process, your administrator specifies both Allowed Scopes and Default Scopes for that API Client. When requesting a JWT access token, your API client can request a set of scopes to be included in the JWT access token.
If the API client doesn’t request any scopes, the scopes specified in the Default Scopes section are included in the JWT access token returned to the API client. If the API client does request scopes, and those scopes are provisioned in the Allowed Scopes for the API Client, the requested scopes are included in the JWT access token. Apply the least privilege principle when you provision an API client in Account Manager. For example, if an API Client requires only access to the Catalogs API, provision only scopes related to the Catalogs API for that client.
Don’t provision scopes for other APIs for that client since additional scopes give the client more privilege it needs. Similarly, if an API Client requires only read access to the Products API, don’t configure the API client with the read/write scope for the Products API. A scope that ends with .rw specifies both read and write access, while a scope that doesn’t end with .rw specifies only read access.
The following example shows the scopes provisioned for an API client that is configured with read/write access to the Catalogs API and read-only access to the Products API.
Apply least privilege when an API client requests a JWT access token from Account Manager. For example, an API client is provisioned with access to both the Catalogs API and Products API. If the API client requires only the Products API, the API client asks only for that scope in the access token. If the API client later wants to call the Catalogs API, the client can request the Catalogs scope.
For details about how to maintain performance, scale, and security for headless commerce applications, refer to the following documents.