Commerce Cloud security best practices overview

I need to ask myself — is my program secured?

Recently, the Commerce Cloud team of Salesforce has released Security Best Practices for Developers which cover major elements to consider when you are building or expanding your e-commerce which is based on the Salesforce Commerce Cloud SaaS platform. In the legacy 201 developer and 301 solution architect courses by SFCC, there is always a separate section that focuses on security. Security was always included in each knowledge category, but not as a specific section by itself. Now, not only do technical teams focus and learn better what security constraints they should pay attention to during development, but it also provides an opportunity for non-technical teams who should be aware of what topics to pay attention to or what questions to ask to ensure that their product is secure.

I did an analysis of the produced documentation and extracted for you a quick overview, so you can decide if you wish, to deep-dive in after it or save your time for the more important stuff.

Photo by Lianhao Qu on Unsplash

• Encryption and Cryptography — to maintain industry-standard compliance frameworks and avoid vulnerabilities, don’t implement custom encryption and cryptography methods. Use industry-accepted and tested cryptographic methods with strong keys. Salesforce B2C Commerce extends Salesforce-maintained cryptography libraries that enable you to safely encrypt, sign, and generate cryptographically strong tokens and secure random identifiers. For more information, you can check under Encryption and Cryptography.
• Cross-Site Scripting — to prevent malicious attacks through content manipulation, you must properly encode all user-provided content. Cross-site scripting (XSS) lets attackers inject malware into a webpage viewed by a targeted user. Use only the appropriate encoding for its respective designed context. For more information, you can check under Cross-Site Scripting.
• Declarative Security via HTTP Headers — you can use declarative security controls as a strong line of defense against client browser-based attacks such as clickjacking and offer built-in browser protection against cross-site scripting (XSS). Declarative security controls via HTTP headers and other client browser-based protections are used only if the client’s browser supports the feature. For more information, you can check under Declarative Security via HTTP Headers.
• Commerce Script Injection — this class of attack lets an attacker control the code executed on the server. Script injection is possible when a script interprets part or all of unsafe or untrusted data input as code, or a snippet of code, and runs it. For more information, you can check under Commerce Script Injection.
• Cross-Site Request Forgery — every storefront contains some protected requests that require a high level of security protection. Authenticated shoppers who change their accounts or submit personal data to a server to complete an action typically perform these requests. Users expect that they alone make these requests, and only when they specifically initiate the request. For sensitive business functions, including a required security token in HTTP requests can help mitigate CSRF attacks. The reason is that to be successful, the attacker has to know the randomly generated token for a particular session. For more information, you can check under Cross-Site Request Forgery.
• Secret Storage — storing and using secrets is one of the most sensitive actions taken to ensure the security of shopper information. You can help prevent data exposure in a number of ways. For more information, you can check under Secret Storage.
• Using Hooks Securely — you can use hooks as a powerful tool to extend default functionality. Like all powerful tools, however, hooks are dangerous if not used properly. Be cautious when using hooks because unprivileged users can make privileged calls. For more information, you can check under Using Hooks Securely.
• Data Validation — 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. For more information, you can check under Data Validation.

Photo by arvin keynes on Unsplash

• Open Redirect Attacks — When a web application trusts user input as a redirect destination, an attacker can use that input to redirect users to a website that they control and steal their information. Follow these best practices:

1. Avoid redirects.
2. Force local redirects.
3. Don’t let users enter the URL as the destination.
4. Validate the URL, if you can’t avoid user input.
5. Map any destination input to a value rather than to the actual URL.
6. Create a list of trusted URLs to sanitize input.
7. Notify users about the redirect, and ask them to click a link to confirm.

For more information, you can check under Open Redirect Attacks.

• Authentication and Authorization — the exploitation of access control vulnerabilities is a core skill of attackers. To combat this, enforce server-side access control checks for business functions such as account management operations, order management operations, and purchasing operations. For more information, you can check under Authentication and Authorization.
• Supply Chain Security — Unverified software sources included through uploads and external linking represent potential vectors for attack. Few of them are code uploads, third-party libraries, remotely hosted resources. For more information, you can check under Supply Chain Security.
• Secure Logging — Salesforce B2C Commerce logs are stored securely. At the same time, we should always consider what types of information to log. Access to the logs usually has developers and site admin. You might have a strong argument to not log sensitive customer information in the logs. For more information, you can check under Secure Logging.
• General Secure Coding Practices — Even with all the security controls that Salesforce B2C Commerce provides, poor coding practices can negate these controls and introduce weaknesses. SFCC recommends referring to the OWASP Secure Coding Practices. For more information, you can check under General Secure Coding Practices.
• AppExchange Security Reviews — LINK Technology Partner applications must go through Salesforce’s security review process before being listed on AppExchange. The security review ensures that the application you publish on the AppExchange meets industry security best practices. For more information, you can check under AppExchange Security Reviews.

My personal opinion with regards to “AppExchange Security Reviews” is that the technical team might need to improve their security validation. In the ‘best practices’ documentation, it describes how credentials should be stored, while multiple numbers of LINK cartridges store credentials in plain text under customer preferences. It is not the security bridge, but it is definitely not the best practice which might cause issues if unauthorized users gain access to sensitive credentials from Business Manager, which is not protected with the proper data type. I would make a strong call that only services should be used for 3rd party credentials, as those are the most secured storage systems when comparing to the custom preferences

Photo by Matthew Henry on Unsplash

A new document released by SFCC on Partner Community is certainly a very positive step forward to ensure that security elements are covered properly on e-commerce solutions which are based on the SFCC ecosystem. The improvements that could be considered are also automation tools based on the Sonar or alternatives to make automated validation of the codebase. We could scan and automatically highlight possible malware or unsecured areas. Otherwise, I would recommend that each technical person read the new document and potentially plan some best practices for regular validation, and incorporating those practices into your operating model.

At OSF Digital, we have a solution for the CI/CD process that can be a part of your release management, it will make validations of your code and data taking into consideration security and the unique verification of the best practices. If you wish to know more, you may contact me under the Unofficial SFCC Slack Community.

My name is Oleg Sapishchuk, and I’m an experienced architect providing digital transformation with unified commerce solutions for some of the world’s best-known and most influential brands. Salesforce B2C Commerce is the topic that I write about most frequently. If you are interested in new or previously written material, I invite you to follow my Medium profile.