Bug or Feature? Uncovering a Potential Salesforce API Security Breach

As you can see, it includes a specific customer ID we’re authenticated for. Furthermore, the signature guarantees the integrity of the token, so there’s no way to decode the payload, change the customer ID, encode that same payload, and use it for another customer.

The problem is that the user who possesses this token can now access any other user's resources. For example, if the agent authenticates as Customer A, they also have the ability to access Customer B resources including personally identifiable information (PII) such as their name, email address, home address, order history, and even their credit or debit card number.

While the token used for these manipulations is specific to Customer A, Salesforce doesn't check customer ID in any of the resource requests, meaning that possessing Token A (signed for Customer A) gives a user the power to access any customer’s data. Thankfully, it only works this way for the agent token that’s given to a business manager when they authenticate on behalf of a customer, and not for the normal user token. But if a signed customer token falls into the hands of a bad actor, they can use it to obtain any customer’s PII. Think of it like stealing one person’s bag and gaining a master key that unlocks any house in their neighborhood.

While Salesforce says this function is working as intended, from this end it looks like a security issue that creates a potential data breach risk — and considering how many companies use Salesforce, the consequences could be significant. With expensive data breaches on the rise, it’s crucial that organizations pay close attention to the design and implementation of their API and perform penetration testing for any feature that interacts with PII to ensure sensitive data stays private.

What do you think: bug or feature?

Pavel Savinov is a software engineer at Heady.