Data Validation

⚠️ 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 €

Validating user input is the basis of application security. Data validation ensures that it is exactly the kind of data that an application expects. Invalid requests are generally rejected outright and an error is returned to users. You can choose where to perform data validation, but we focus on client- and server-side validation.

  • Client-side validation is typically implemented via scripting language to check data on a client machine before sending it to a server. On Salesforce B2C Commerce, you write JavaScript code that runs in a user's browser and validates form data. However, client-side validation isn't reliable as a security control.

  • Server-side validation is implemented by writing an additional step into a business flow. This step is an effective security control. Developers typically perform server-side validation in a B2C Commerce script, using the B2C Commerce APIs and some basic sanity checks.

Basic data sanity checks using client-side validation can give storefront users immediate feedback. Whereas using robust server-side validation can stop malicious requests.

After the request is sent, validate the data again. If the data is invalid, B2C Commerce halts processing and informs the user via an error message. As a result, accidental, mistyped data is reported to legitimate users via client-side validation, while malicious users sending requests directly to servers are stopped by server-side validation.

Protect Against Injection Attacks

Proper validation protects against injection attacks. When used with output encoding, it provides an even more robust defense against injection attacks. Here are some considerations.

  • Exposing sensitive internal data in client-side validations:

Don’t use too much internal logic with client-side checks when validating data. This risks exposing lists of expected values or potentially valid data to the client to check against. Doing this can give away valuable data to all clients, including malicious attackers searching for vulnerabilities.

  • Inexact validation that leads to a false sense of security:

Avoid relying too heavily on validation for security. Validation steps are just one piece of a larger, in-depth security control that promotes multiple stages of security checks. This practice is a common problem, especially with regular expressions because they are difficult to verify exhaustively.

You can validate user input in the following ways.

Validate User Input Via... Description
Allowlisting

Allowlisting is the most strict validation strategy. You define what an acceptable input is and reject everything else. For example, if the input is for a day of the week, only seven known values are expected.

You can also allowlist the format of input. For example, dates and Social Security numbers have a specific format.

Blocklisting

When the input can take too many forms to be allowlisted, blocklisting is an effective option. Use blocklisting to block certain types of input that are known to be inadmissible. You can't identify all potentially bad input, but consider the following questions when you implement blocklisting.

  • What is the appropriate length of the input?
  • What character sets should we allow or disallow?
  • Is supporting only numeric, alphabetic, or alphanumeric an option?