---
schema_version: "1"
id: 846b6e3feca28b05ecf8439863370b12b8bf0f58190952db7916633113485f44
title: Data Validation in B2C Commerce
collection: admin
version: current
locale: en-us
portal_url: https://docs.salesforce.com/admin/current/en-us/cc/264-0-0/b2c_data_validation.md
canonical_url: https://help.salesforce.com/s/articleView?id=cc.b2c_data_validation.htm&release=264.0.0&type=5
source_site: help.salesforce.com
content_type: documentation
content_hash: b87fcbb1a1de0f5578da551c95f65c6bb511a7305261728ef4ae933bd249741e
description: Validating user input is the basis of application security. Data validation ensures that it is exactly the kind of data that an application expects. B2C Commerce generally rejects invalid requests outright and returns an error to users. Choose where to perform data validation, but we focus on client- and server-side validation.
products:
  - Commerce
  - B2C Commerce
release: "264"
---
# Data Validation in B2C Commerce

Validating user input is the basis of application security. Data validation ensures that it is exactly the kind of data that an application expects. B2C Commerce generally rejects invalid requests outright and returns an error to users. 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.
- To implement server-side validation, write 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, client-side validation reports accidental, mistyped data to legitimate users, while server-side validation stops malicious users sending requests directly to servers.

## 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.

Validate user input in the following ways.

<table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small ">
        <colgroup>
          <col>
          <col>
        </colgroup>
        <thead class="slds-text-title_caps ">
          <tr class="">
            <th scope="col" class="slds-cell-wrap" style="vertical-align:top;" id="d200470e94"> Validate User Input Via... </th>
            <th scope="col" class="slds-cell-wrap" style="vertical-align:top;" id="d200470e97"> Description </th>
          </tr>
        </thead>
        <tbody>
          <tr class="">
            <td data-label="Validate User Input Via..." class="slds-cell-wrap" style="vertical-align:top;" headers="d200470e94 ">Allowlisting</td>

            <td data-label="Description" class="slds-cell-wrap" style="vertical-align:top;" headers="d200470e97 ">
              <p>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.</p>
              <p style="margin-bottom:0;">You can also allowlist the format of input. For example, dates and Social
                Security numbers have a specific format.</p>
            </td>

          </tr>
          <tr class="">
            <td data-label="Validate User Input Via..." class="slds-cell-wrap" style="vertical-align:top;" headers="d200470e94 ">Blocklisting</td>

            <td data-label="Description" class="slds-cell-wrap" style="vertical-align:top;" headers="d200470e97 ">
              <p>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.</p>
              <ul>
                <li> What is the appropriate length of the input? </li>

                <li> What character sets are supported? </li>

                <li> Is supporting only numeric, alphabetic, or alphanumeric an option?
                </li>

              </ul>
            </td>

          </tr>
        </tbody>
      </table>