Loading...
Back to Blog
OWASP Top 10: A Guide for Salesforce Experts

OWASP Top 10: A Guide for Salesforce Experts

Lorenzo Frattini

It’s fascinating how AppSec teams working with Salesforce adopt OWASP Top 10 Guidance and integrate these recommendations in their Salesforce security tools.  It leads to interesting conversations about Salesforce security scanners, penetration testing, and the like.

I think an analysis of what it means for the Salesforce community would be helpful for the many out there who care about security but find OWASP guidance a bit generic or hard to apply.

Feel free to share your thoughts!

(01) Broken Access Control

What is it?

This risk occurs when users can do things outside their intended permissions.

Should I care?

Yes, very much. All custom developments are at risk: this can lead to unauthorised information disclosure (data leaks), modification or destruction of all data or performing a business function outside the user’s limits.

Examples

Some common vulnerabilities that are relevant to Salesforce development include:

(02) Cryptographic Failure

What is it?

This risk occurs when sensitive information is not safeguarded. This can be due to a wide variety of reasons, for example: hardcoding passwords, storing secrets in plain text, or using insufficiently robust encryption.

Should I care?

Yes. Although out-of-the-box functionality is robust, any custom logic is potentially at risk. Admins may introduce this vulnerability through low-code.

Examples

Some common vulnerabilities relevant to Salesforce development include:

  • Using a weak encryption algorithm (for example, SHA1, MD5)
  • Using a weak encryption key (for example a hardcoded string)
  • Setting a user’s password programmatically instead of delegating password generation to the platform
  • Storing passwords, tokens or other secrets insecurely, for example, using text fields instead of using Field Encryption or Protected Custom Settings (only for managed packages)

(03) Injection

What is it?

This risk occurs when it’s possible to submit user-supplied data directly to the application in a way that is directly interpreted or executed. This allows a malicious actor to execute commands or retrieve data they aren’t supposed to see.

Should I care?

Yes, very much. Injection attacks are possible and more likely every day. These kind of vulnerabilities are extremely common in Salesforce deployments that involve custom code.

Examples

Some common vulnerabilities that are relevant to Salesforce development include:

(04) Insecure Design

What is it?

This one is more for Salesforce architects and less for developers. It’s a broader risk that doesn’t relate to any specific vulnerabilities but rather to the lack of controls in the development lifecycle.

Should I care?

Yes. Without appropriate controls in the lifecycle, security will not be addressed, leaving the application at risk.

Examples

  • Not adopting the principle of “least privilege.”
  • Not factoring in security requirements in the analysis and design phases
  • Performing security scans post-release, as opposed to early during development

(05) Security Misconfiguration

What is it?

This is a very broad risk that includes improperly configured permissions.

Should I care?

Yes, this one is fundamental. Especially when using a complex, highly configurable cloud service such as Salesforce, the risk of misconfiguration is very likely and very serious. You don’t need custom code to be exposed to this risk.

Examples

Pretty much everything in Salesforce could be misconfigured (i.e. OWD, role hierarchy, permission sets, profiles, etc) making this risk both extremely likely and complex to address. For developers using custom code, some common security misconfigurations include:

  • Lightning Locker bypass
  • Excessive data access privileges (e.g. in profiles and permission sets)
  • Hardcoding password when creating users
  • Insecure sharing with external users

(06) Vulnerable and Outdated Components

What is it?

This risk occurs when one of the components or libraries you use to accelerate developments has a known vulnerability.

Should I care?

Yes, very much. Bad actors are well aware of known vulnerabilities and often use these types of weaknesses to exploit applications.

Examples

Using open-source components is commonly done to provide richer user experiences. Vulnerable components are typically found in:

  • In Visualforce pages and components
  • In Lightning Aura Components
  • In Lightning Web Components
  • In your static resources and bundles

(07) Identification and Authentication Failures

What is it?

This category of risk is typically related to how sessions and authentication are handled.

Should I care?

Yes, at least to a degree. In most circumstances, these scenarios are handled robustly by the platform itself. However, there are a few examples in which custom logic can introduce this vulnerability, particularly if you don’t think too much about it.

Examples

  • Storing sensitive data such as passwords, and secrets in the database (plain text)
  • Setting user password programmatically via Apex
  • Hardcoded credentials (not using name credentials)

(08) Software and Data Integrity Failures

What is it?

This is a new entry of 2021. It refers to the risk of embedding logic in your application or consuming external data without verifying its integrity.

Should I care?

Yes, to a degree. Although this may be unlikely in a Salesforce deployment, some recent exploits, such as the SolarWind attack and the CodeCov Bash Uploader Compromise, leveraged this vulnerability class.

Examples

There are several ways in which custom logic can be vulnerable to software or data integrity issues.

  • Deserialisation of Untrusted Data
  • Embedding scripts insecurely (e.g. over HTTP)
  • Embedding scripts from untrusted sources

(09) Security Logging and Monitoring Failures

What is it?

This refers to the risk of not logging security events properly, such as user accesses.

Should I care?

Probably not. Although this is quite broad, this risk is largely mitigated by the Salesforce platform and its robust controls around identity, access and event logging.

(10) Server-Side Request Forgery (SSRF)

What is it?

This risk is a new raised by the OWASP community, which has a relatively low incidence. It’s generally related to how modern application process URLs in order to provide better user experiences — a mechanism that could be exploited in some circumstances.

Should I care?

Probably not. In most cases, it’s unlikely for Salesforce developers to model this type of behaviour, as URLs are managed natively by the platform as custom fields.

How to prevent

You can prevent these risks by "shifting-left" your security. This means embedding clear and repeatable security controls into both the design and development processes.

During design:

During development:

  • Adopt secure code reviews in your development lifecycle
  • Add vulnerability scanning tools to your CI/CD pipeline

Post go-live:

  • Adopt Cloud Security Posture Management (CSPM) tools

Share on social media: 

Get ahead.

Join 1000+ Salesforce professionals who receive critical reading, insights and expertise written just for them, from the team at Clayton. Once a week.
Unsubscribe with one click.

More from the Blog

Webinar - Optimize your Apex code with the new Null Coalescing Operator

A 30-minute education session to learn the essential Spring '24 features for Architects and Developers.

Read Story

Watch the Video - The State of Salesforce Development in 2024

Watch the recording of our recent webinar, with Clayton's team and experts from Silverline exploring data and benchmarks for the State of Salesforce Development heading into 2024.

Read Story

Wrapping Up 2023

As we bid farewell to 2023, let's take a moment to look back at the year that just passed. Let's celebrate together by looking back at the favourite features we shipped this year!

Read Story