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:
- Apex sharing violations
- CRUD and FLS bypass
- Insecure Direct Object References (IDORs)
- Cross-Site Request Forgery (CSRF)
(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:
- Integrate security requirements into user stories
- Adopt the Principle of least privilege
- Use some form of Threat Modelling in your design stage
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
.png)
