CSRF Protection in Business Manager
A CSRF attack is a technique used by malicious attackers to force a victim to make a protected request to Business Manager ― a request that can severely disrupt your eCommerce business.
CSRF Attacks
All Business Manager pages are automatically protected from CSRF attacks. Whenever a Business Manager page makes a request to the Commerce Cloud server, the page automatically injects a special CSRF token into the request. When the server receives the request, the server determines whether the request is trying to perform a protected (potentially harmful) action. If the request tries to perform such an action, the server automatically validates the injected token. If it can successfully validate the token, the server completes the protected action and returns the expected response; otherwise, starting in 17.4 in SIGs and 17.5 in PIGs, the server logs a warning and in some cases returns an error page. For example:
If you see an error page like this one, you can follow the given steps and retry the page where the error occurred. If the retry succeeds, you can ignore the error; but if the retry fails and you see the error again, you are likely experiencing ― and being protected from ― a CSRF attack. In this case, you should contact your security department.
Not all CSRF-related errors or log entries indicate an attack. If you are a Salesforce admin, you can troubleshoot CSRF log entries to investigate their underlying causes and determine an appropriate course of action. In some cases, if you are using a custom Business Manager extension, you might require that a developer modify the extension's custom code to properly insert CSRF tokens. In other cases, you might choose to allowlist either a specific pipeline or user agent.
Troubleshooting CSRF Log Entries
CSRF log entries have the following format:
Pipeline CSRF Token not valid[reason]: pipeline: (token|no_token):: Referer/Origin: URL:: UserAgent: agent
where:
-
reason is a string explaning why the validation failed.
Some possible reasons are:
- Origin validation― the request came from a website that isn't a Business Manager page.
- No token― the request was made without a CSRF token.
- CSRF token validation― the token is incorrect for this user, or it has timed out (1 hour timeout).
- Exception occurred― something unexpected happened during processing (this is a catch-all).
- pipeline is the name of the pipeline in the request.
- token is the token received by the server (if one was sent in the request).
- no_token is a string indicating that no token could be found in the request: "CSRF Token doesn't exist."
- URL is a URL indicating where the request originated.
- agent is the first 30 characters of the user agent.
You can find these entries in your log files by searching for the string "Pipeline CSRF Token."
See Log Center.
Log entries are created whenever the server expects a valid CSRF token, but either can't find one, or finds an invalid one. There are several situations in which this might happen, described in the following table:
| Situation | Possible remedy |
|---|---|
| The Business Manager user was attacked. If the user reached the error page after visiting another site, the other site might have tried to make a protected request to Business Manager, and the framework has properly protected against the attack. | The Business Manager user should report this attack to their security department. |
|
The Business Manager user was not attacked, and the log entry suggests that no token was found. A likely cause is that the automatic token injection failed to inject properly in custom Business Manager extensions. Commerce Cloud has discovered several places where this might happen, including:
|
A developer can manually add the token by using the
to this: |
| The Business Manager user was not attacked, and the log entry suggests that the token was invalid. Because tokens become invalid after 60 minutes, it's possible for the user to return to an old browser tab and make a request that fails to validate. This might also occur on a small number of pages that update the data shown within that page without navigating to another page within Business Manager. | The Business Manager user can refresh the page where the error occurred. |
| The Business Manager user was not attacked, but instead of making the request to the server from a Business Manager, the user made the request from an email, a bookmark, or a separate website. |
If you want to enable users to make requests from emails, bookmarks, or separate websites, the recommended approach is to create a new start node in the pipeline that would serve as a safe redirect to the desired page. This task must be performed by a developer. When the developer completes this task, an administrator can allowlist the redirect pipeline-start node combination. This disables CSRF validation for that start node for all users. |
| The Business Manager user was not attacked, but the request can't be protected or has not been protected yet. | An administrator can use a CSRF allowlist to temporarily disable validation on either the pipeline or pipeline/start node combination. This is generally not recommended. |
| An automated script is used to collect data from a Business Manager instance, or to import data for automated testing. |
An administrator can use a CSRF allowlist to allow the User-Agent of the script. It's strongly recommended that if this approach is used, a non-browser User-Agent string is utilized. This will disable the validation logic for all requests where the User-Agent exactly matches that allowlisted value. Alternatively, customers can choose to give the automated scripts knowledge of the CSRF token (which is embedded in every Business Manager page) and use the token in script-based requests. This will mimic the behavior of browser-based navigation and is the recommended approach. |