We had discussed in our previous blog post on why it is important to review applications developed in salesforce platform. In this one, we will discuss the common vulnerabilities we observe along with the method to detect the same in the code.
1. Open Redirects
An attacker uses an HTTP parameter that contains a URL value to cause the web application to redirect the request to this specified URL, which may be outside the application domain. An attacker sets up a phishing website in order to obtain a user’s login credentials. The attacker then uses the redirection capacity to provide links that appear to point to a legitimate application domain, but actually point to a malicious page to capture login credentials. The stolen user credentials can then be used to log-in to legitimate web sites. Attackers can exploit this to redirect victims from trusted Salesforce domains to malicious websites.
How to Detect in Code
- Look for use of PageReference in Apex code where the URL is directly consumed by user input without performing validation –
String target = ApexPages.currentPage().getParameters().get('url');
return new PageReference(target); // ❌ Vulnerable
- Another method is to check JavaScript in Visualforce, LWC, or Aura where navigation functions accept URLs without performing any validation.
Impact
Attackers can use open redirects to launch phishing attacks, steal Salesforce credentials or trick users into downloading malware. Since the redirect originates from a trusted Salesforce domain, end users are far more likely to trust the malicious destination and become victim of this attack.
2. Hardcoded Secrets in Apex / Insecure Storage of Sensitive Data
"Hardcoded Secrets" represents a critical security concern where sensitive information, such as passwords, API keys, OAuth tokens, cryptographic secrets or credentials, is embedded directly into an application's source code or configuration files specially in Apex classes, custom settings, or custom metadata. These secrets are often visible to anyone with access to the application's codebase, and they pose a significant risk.
Many developers make the mistake of defining custom object fields as "public". This makes their secret values available in plain text. As an example, the metadata snippet shown below marks the API key field as visible.
How to Detect in Code
- Hardcoded Secrets in Apex Code - Search for API keys, access tokens, passwords, or cryptographic keys directly assigned to variables. Check for sensitive constants declared in classes. Moreover, Search for suspicious keywords like "password", "apikey", "secret", "token".
// Insecure: Hardcoded API key
String apiKey = 'ABCD1234SECRETKEY';
- Sensitive Data in Custom Objects or Metadata - Inspect custom object definitions (.object files in metadata). Look for <visibility>Public</visibility> in sensitive fields such as apiKey__c, secret__c, or token__c.
Insecure code in Object file
<fields>
<fullName>apiKey__c</fullName>
<type>Text</type>
</fields>
<visibility>Public</visibility>
Secure Code in Object file
<fields>
<fullName>apiKey__c</fullName>
<type>Text</type>
</fields>
<visibility>Protected</visibility>
Impact
Hard-coded secrets are vulnerable to unauthorized access, exposure, and misuse, potentially leading to data breaches, security incidents, and compromised user accounts. In case of salesforce, if an API key meant for admins is leaked using one of the above mentioned method, an attacker can use the key to communicate with Salesforce and/or another external service and take data out of provisioned channels.
3. Sensitive Data in Debug Logs
Salesforce allows developer to write information in logs using System.debug(). A privileged user i.e. administrator is able to access logs and can gain access to sensitive information i.e. PII data, financial records, SSN or PHI if logged.
How to Detect in Code
- Review System.debug() statements in Apex for exposure of fields like SSNs, payment details, or authentication tokens.
System.debug('User password is: ' + password); // Never log this
Impact
The risk of unauthorized disclosure increases if the logs are exported or shared. This also violates compliance requirements of GDPR, HIPAA, PCI-DSS.
4. Wide OAuth Scope
Managing the overall access of the application is also very crucial. Excessively exposed integrations with apps or OAuth tokens featuring broad scopes, like full or refresh_token, put the app at risk by providing more access than necessary.
How to Detect in Configurations/Code
- Review OAuth connected app definitions and check requested scopes.
- Look for integrations where the full scope is used instead of narrowly defined scopes.
Impact
Large volumes of Salesforce data could be read, modified, or even deleted by overly permissive OAuth tokens.
5. Insecure CORS Configuration
CORS is implemented to limit which other sites can request Salesforce’s resources. When configured to allow * (any origin) or unnecessary domains, it opens the door of cross domain attacks.
How to Detect in Configurations
- Check Salesforce CORS settings under Setup → CORS.
- Look for entries that allow overly broad or untrusted origins.
Impact
If CORS is not correctly configured, an attacker can create a site which can lead to Cross-Site Request Forgery (CSRF) or Cross-Site Scripting (XSS) attacks, where an attacker can exploit the permissive CORS policy to perform malicious actions on behalf of a user.