Salesforce B2C Commerce 24.5 > Administering Your Organization

CSRF Protection in Business Manager

⚠️ The annual cost of maintaining the server where this website is hosted, the domain, and keeping it up-to-date is approximately €3,000 per year. Help us with a small donation to cover these expenses. Support Now!

0 / 10000 €

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 URL formed inside of a JavaScript variable, as an argument for a JavaScript method, or as an onclick handler. A URL formed inside of a `<meta>` tag, in particular, refresh. A URL formed inside of an `<isset>` or custom-defined tags. A URL defined inside of a pipeline, pipeline dictionary, or code.	A developer can manually add the token by using the `dw.web.URL.appendCSRFTokenBM()` method. For example, the developer could change the following code: `<meta http-equiv="refresh" content="0; URL=${dw.web.URLUtils.url('ViewAccount-Show').toString()}">` to this: `<meta http-equiv="refresh" content="0; URL=${dw.web.URLUtils.url('ViewAccount-Show').appendCSRFTokenBM().toString()}">`
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.