The OWASP Top 10 has changed: a guide for Salesforce experts
The OWASP Top 10 is a summary of the most relevant security risks for application developers.
I have been working with Salesforce technology for quite some time; when it comes to InfoSec I’ve experienced some serious disconnect between industry guidance and how teams approach security in the real world.
Four years after the previous issue, OWASP has released an updated Top 10 in September 2021.
I thought an analysis of what it means for the Salesforce community would be helpful for the many out there that care about security but find OWASP guidance a bit generic or hard to apply.
How to read this post
In this post, I take the latest OWASP Top Ten and break it down from the point of view of a Salesforce expert (with particular attention to architects and developers). I have kept the original order from OWASP. For each vulnerability, I provide the following:
- What is it? — A simplified explanation of the risk
- Should I care? — A comment on how relevant the risk is to Salesforce developers
- Examples — A few vulnerabilities or scenarios that Salesforce developers should be familiar with, to illustrate how the risk may manifest itself
- How to prevent? — A few notes about approaches and tooling to prevent, detect or mitigate
My breakdown of the OWASP Top 10 for Salesforce experts.
(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:
- Apex sharing violations
- CRUD and FLS bypass
- Insecure Direct Object References (IDORs)
- Cross-Site Request Forgery (CSRF)
How to prevent?
- Adopt secure code reviews in your development lifecycle
- Add vulnerability scanning to your CI/CD pipeline
(02) Cryptographic Failure
What is it?
This is risk occurs when sensitive information is not safeguarded. This can be due to a wide variety of reasons, for example: hardcoding password, 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)
How to prevent?
- Adopt secure code reviews in your development lifecycle
- Add vulnerability scanning to your CI/CD pipeline
(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:
How to prevent
- Adopt secure code reviews in your development lifecycle
- Add vulnerability scanning to your CI/CD pipeline
(04) Insecure Design
What is it?
This one is more for 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
How to prevent
You prevent this risk by “shifting-left” security. This means embedding clear and repeatable security controls into how you run both design and development. A few tips:
- Integrate security requirements into user stories
- Adopt the Principle of least privilege
- Use some form of Threat Modelling in your design stage
- Adopt secure code reviews in your development lifecycle
- Add vulnerability scanning to your CI/CD pipeline
(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
How to address
- Adopt secure code reviews in your development lifecycle
- Add vulnerability scanning to your CI/CD pipeline
- Explore Cloud Security Posture Management (CSPM) tools
(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 this type 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
How to address?
- Adopt secure code reviews in your development lifecycle
- Use Software Composition Analysis in your CI/CD pipeline
(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 be 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 password, secrets in the database (plain text)
- Setting user password programmatically via Apex
- Hardcoded credentials (not using name credentials)
How to address
- Adopt secure code reviews in your development lifecycle
- Add vulnerability scanning to your CI/CD pipeline
(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 their 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, both leveraged this class of vulnerabilities.
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
How to address
- Adopt secure code reviews in your development lifecycle
- Add vulnerability scanning to your CI/CD pipeline
(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 seems to have 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.
What’s your take?
I couldn’t find much discussion on this topic yet. However, I am very interested in how AppSec teams working with Salesforce adopt OWASP Guidance. Feel free to connect and share your thoughts.
