Salesforce has remained a top choice for enterprises when it comes to building applications. Thanks to its flexibility, scalability, and rich set of features, organizations can build applications tailored to their workflows seamlessly. But then again, a question arises: Do I need to worry about security if I write the application on salesforce platform?
A common misconception that the app is secure often comes up when businesses develop apps or customizations on the platform. And the answer is, “Yes” (reasons for the same are well described in another blog entry under “The Importance of Security Reviews for Applications on Enterprise Platforms” Even though Salesforce offers a robust and secure platform, it is your responsibility to secure your own custom code, configurations, and integrations.
Salesforce Application Overview
The applications built with Salesforce are normally structured across two core layers with a unique purpose. However, these layers also tend to introduce potential security considerations.
- Client-Side (User Interface Layer): As the name implies, the client-side layer that can be implemented in many frameworks is responsible for managing user interactions with the application. Visualforce Pages is an older, page-based framework for creating user interfaces with business logic embedded inside. Aura Components and interface creation are great tools, but the mishandling of attributes and methods can pose security-related issues. Lightning Web Components (LWC) represent Salesforce’s modern, standards-based framework. In LWC, web components are used to enhance performance. Moreover, these components also offer strong security.
- Server-Side (Business Logic Layer): The application’s business logic, data processing are typically implemented on server-side layer. Salesforce programming language is Apex which is similar to Java. Apex code is mainly used for database operations, process and business rules implementation. Even though Apex code provides wide range of capabilities to build a business logic, the use of improper and unsafe coding at this layer may lead to serious security risks. These layers definitely make the Salesforce applications flexible and scalable. However, they create multiple entry points that can cause security vulnerabilities if not checked or secured properly.
The Significance of Security Reviews
Salesforce undergoes rigorous security testing and compliance. Based on the requirements, either you, your team, or a partner develops custom apps, Apex code, Visualforce pages, Lightning, and integrations. If there are any flaws in any of the layers, attackers could gain access to Salesforce org, go through private client data, or raise compliance issues.
In other words, Salesforce ensures the platform security, while the application team must ensure the security of what they have built on the platform.
Choosing the Right Salesforce Testing Method: Black-Box vs. White-Box
When reviewing a Salesforce app, one can choose between -
- Black-box testing is the process of when the tools simulate an attack as if they were an outside attacker, without any prior knowledge. This helps to find issues such as injection points, misconfigured endpoints, and authentication problems.
- White-box testing refers to the practice whereby the tester has full access to the code/configuration/metadata. This technique often reveals logical errors, dangerous storage, bad sharing policies, and API misuse that black-box analysis wouldn’t usually detect.
A combination of the two is the best strategy. The internal aspect of the configuration and logic is secured as a result of the white-box test. The black-box test verifies the attack surface externally.
Security Concerns to Take into Account in Salesforce
Understanding specific risks that go beyond those of conventional web applications is necessary when scoping a Salesforce security review. Here is the list of some of them -
- CRUD/FLS Bypass – if Create, Read, Update, Delete, or Field-Level Security checks are not performed properly, it may leak sensitive data.
- Insecure Sharing Settings/Sharing Violation – Access to restricted records can be unintentionally shared if the code is running without sharing.
- SOQL Injection –. If user inputs are directly passed in SOQL queries (without any processing or validation) it can lead to data leakage due to SOQL query manipulation.
- Cross-Site Scripting (XSS) – Fail to validate user inputs in Visualforce, Aura, or LWC can lead to XSS attack.
- Open Redirects – Phishing or session hijacking can become very common if the JavaScript functions and PageReference redirections are used without validation.
- Hardcoded Secrets in Apex / Insecure Storage of Sensitive Data – Credentials, tokens or sensitive information are stored in plaintext as part of the code or in configuration or database.
- Sensitive Data in Debug Logs – if System.debug() is set, an administrator can get access to sensitive data by accessing logs of the application.
- Wide OAuth Scope – While integrating Salesforce with third party applications, typically OAuth protocol is used. In the implementation of OAuth, if OAuth scope is set to full instead of necessary requirement, it will allow third party applications to access excessive data and functionality of Salesforce.
- Insecure CORS Configuration – One can exploit weak implementation of CORS to make calls to Salesforce APIs.
- Overexposed APIs – Sensitive data can be exposed if the application fails to restrict appropriate use of Salesforce APIs.
The Significance of Configuration Review and Permissions
Manual pen testing and code review go a long way in ensuring that security parameters are up to the mark but there are multiple permission settings and incorrectly configured security controls that can compromise even the most secure code. Examining Salesforce's permission model is just as crucial as running code tests:
- Profiles and Permission Sets – Make sure users only have access to what is require.
- Role Hierarchy and Sharing Rules – Avoid exposing too many private documents.
- Field-Level Security (FLS) – Prevent unauthorized users from reading or altering sensitive fields.
Misconfigurations in these areas are one of the most common sources of breaches in Salesforce environments.
Conclusion
In conclusion, Salesforce platform provides a secure foundation, but the additional layers, functionalities and customization on the platform need to be reviewed to make sure that the security controls provided by Salesforce platforms are implemented correctly. To build a secure application, the focus of the review should be on platform specific vulnerabilities and use of secure coding best practices along with the classic web application vulnerabilities. The combination of black-box, white-box along with deeper permission and configuration review will make sure that the application is secure.
We are going to write about the key vulnerabilities we normally discover while performing salesforce security review in our next entry.