Security Considerations for Headless Commerce
Shared Responsibility Model
In a headless commerce system, the custom head typically includes front-end applications that provide the presentation layer (UI) and a back end that serves content to the front end. In this design pattern, referred to as back-end-for-front-end (BFF), the back end of the custom head communicates with the Salesforce Commerce API.
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.
See B2C Platform Shared Responsibility Model for more information.
Headless Commerce Security Features
B2C Commerce provides authentication, authorization, and availability features for headless commerce.
Authentication ensures that callers are who they say they are. An administrator provisions an API client with a secret. The client specifies that secret when requesting an access token. The API gateway authenticates based on the access token. For more information, see Commerce API Authentication.
Authorization (AuthZ) validates access to a particular resource and ensures that callers have permission to perform 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 Client Permissions for API Endpoints.
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 Commerce API Rate Limiting.
General Security Best Practices
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.
B2C Headless Security Best Practices
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 Client Permissions for API Endpoints, 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.
We also recommend that you review following documents, which contain useful information about customer trust and security.