Implementing SaaS security best practices can be challenging as they are often undocumented and poorly understood by security teams, business admins, and developers, leading to misconfigurations that can often pose a more significant risk than exploitable vulnerabilities.
To make matters worse, these misconfigurations become more common and potentially damaging as platforms increase in complexity. Founded in 1999, Salesforce was one of the first SaaS applications that, over time, has evolved into one of the most complex SaaS platforms due to its numerous supported integrations, privilege sets and usage models. This complexity has exponentially increased the likelihood of mistakes, misconfigurations and misuse.
What are Named Credentials?
Named credentials is a useful feature that helps Salesforce developers using Apex (a language proprietary to Salesforce) to avoid the use of hardcoded credentials and endpoints in code. Using hardcoded credentials poses a well-known risk that developers have to manage especially if they are saved in code, in plain text, making them easy to steal and abuse. Indeed, stolen credentials have been the entry point for the majority of breaches, according to the Verizon 2023 Data Breach Investigations Report, with 86% of all breaches involving the use of stolen credentials.
Alternately, the use of the named credentials feature in Salesforce is very flexible and potentially more secure, supporting different types of authentication such as OAuth and API keys. Even custom headers can be defined and based on contextual information, like relative user properties, for example. Ultimately, this feature is designed to keep cleartext credentials out of code, reducing the chances of data leakage.
So, Apex developers should embrace the use of named credentials and security is ensured, right? Not quite - there is a right and wrong way to use this feature.
Attack Scenarios
Named credentials lacking tightly controlled permission sets or other restrictions can actually be very useful to attackers. A malicious application, malicious insider or attacker that has stolen access tokens to your tenant could use a named credential to access other applications and their data, tenant-wide. Some of this data could also include other named credentials and access tokens, which could lead to more pivot opportunities and so on.
It’s worth noting that named credentials don’t necessarily just contain proprietary secrets. There are scenarios where stolen credentials could lead to pivots across an organization, across SaaS platforms, or even between partners and customers! The 2022 breach involving Heroku, Travis-CI and GitHub is one example where this was a key factor.
The attack possibilities are as complex as the mesh that interconnects SaaS platforms and trust relationships.
Using Named Credentials
Defining and using a named credential looks like this:
HttpRequest req = new HttpRequest();
req.setEndpoint('callout:Named_Credential_Name/path/to/your/endpoint');
Once the request is sent, Salesforce will replace callout:Named_Credential_Name with the necessary authentication keys, and will add any headers required for the session. This implementation is very convenient, as it automates a lot of additional work, eliminating additional coding. Also, since this replacement is handled server-side, no plaintext credentials are exposed.
Securing Named Credentials
Simpler code is easier to read and secure, right? This is often true, but there is still a right and wrong way to use named credentials. In the following example, a Salesforce admin wants to connect the GitHub API to create issues in a specific project, from Salesforce.
❌ The insecure way to do it:
- define NamedCredential.Endpoint: "https://api.github.com"
This will allow an attacker to do the following:
HttpRequest req = new HttpRequest();
// see all scopes granted to the api key
req.setEndpoint('callout:GithubCreds/authorizations');
// create an invite to the organization
req.setMethod("POST")
req.setBody('{"role": "admin", "email": "attacker@evil.com"}')
req.setEndpoint('callout:GithubCreds/orgs/MyOrg/invitations');
Configuring the named credential this way, for example, may allow an attacker to jump between SaaS platforms, beyond the intended and necessary context of the application. Integrations are often consented by SaaS admins, and given high privilege levels to avoid having to troubleshoot permissions issues. Attackers are aware of this and target these integration points.
Why would a developer take this shortcut? Developers are typically incentivized to just Get Stuff Done. Often, the more secure method requires additional research, troubleshooting, and effort that can delay delivery, pushing work into the next sprint.
If developer incentives prioritize speed and quantity over quality, creating broad authorizations is a potential shortcut that saves time but introduces potential security risks.
✅ The secure way to do it:
- Generate a GitHub API key, applying the principle of least privilege
- Configure your named credential with an explicit URI that cannot be abused by appending data. For example:
define NamedCredential.Endpoint: “https://api.github.com/repos/MyOrg/SalesforceRepo/issues”
By applying the principle of least privilege, we’ve made this named credential considerably more secure and resilient against abuse. Even if compromised, the attacker’s actions will be limited to a very narrow scope, and the ability to pivot with these credentials will be limited, if not impossible.
Conclusion
Salesforce Apex code and named credentials can be powerful tools when used and configured correctly. Misconfigurations are common, especially with developers focused more on fast delivery than security. Organizations need to educate developers and enforce SaaS security best practices when implementing these features.
This is the latest research from Valence Threat Labs, but more is coming. Keep an eye out for breach analysis, SaaS vulnerabilities, and SaaS security insights in the near future. Also go to the Valence Threat Labs page to get more info on the latest SaaS risks, and to the breach guide for latest SaaS-related breaches.
See the Valence Platform in action
Valence's SaaS Security Posture Management (SSPM) solution makes it easy to remediate risks across your SaaS applications.
In 20 minutes learn how you can:
- Discover all your users, permissions and integrations
- Define SaaS security policies and enforce them with automated workflows
- Scale remediation workflows by engaging with business users
- Quickly remediate data, identity, SaaS-to-SaaS integration and misconfiguration risks
Schedule a demo now to see the platform in action.
.jpg)
