Building trust requires more than just rigorous technology. It requires a transparent partnership between Salesforce, our customers, and the global security research community. To our customers, this story offers a look at the diligence we apply to every potential threat. To our partners in the research community, it is a testament to the critical nature of your work.
Security researchers are the ones who follow the clues, test the boundaries, and report what they find. But the process does not end with the report. A security investigation is a journey to find the root cause, even when the path takes an unexpected turn. This case study highlights our dedication to digging deeper, because a thorough investigative process is a critical part of the foundation of a secure platform.
The Report: A Plausible Threat
Our investigation began after we received a report about a possible service disruption issue affecting one of our e-commerce platforms. The report described a way to send an unusually large and specially formatted request to the system that could cause it to slow down or stop responding. During the researcher’s testing, this resulted in a delayed error response that appeared after about 60 seconds. The researcher suggested this was evidence of system resource exhaustion and our systems were not properly blocking the request.
The Investigation
Our initial review indicated that our edge security controls were operating as intended. The majority of malformed requests were correctly rejected with a standard “413 Payload Too Large” error. Based on these results, we initially believed that the researcher was experiencing a localized or connection-specific issue, rather than a problem that posed a broader risk to the availability of the platform.
The researcher didn’t give up. They showed us a clear example of how to trigger the 60-second timeout. This is where working together really matters. The detailed information from the research community helps our teams recreate the exact conditions of a possible issue. Thanks to their hard work, we expanded our testing parameters to account for these specific conditions.
Our engineers ran the test, and sure enough, the system hung for exactly sixty seconds. It looked like the researcher was right: the bug was real, and it was on our platform. We told them we were working on a fix. But when we started digging into the logs to solve the problem, the story changed. The answer wasn’t in the code; it was hidden in the network traffic.
The Discovery
We noticed something missing. The timeout responses didn’t have the standard tracking stamps we add to every request. This was a huge clue. It meant our application never even touched the request. Instead, we found a fingerprint we didn’t recognize: an “x-optimized-by” header from a third-party service.
The drawing below illustrates the request’s actual path.
The request wasn’t crashing our servers. It was getting stuck at a checkpoint miles upstream. The “resource exhaustion” was actually just a default timeout setting on a proxy server we don’t control.
The Takeaway
This investigation shows two important things about modern cloud security.
First, the truth isn’t always convenient. We followed the evidence, even when it pointed to a flaw in our own systems. When the evidence shifted, pushing our investigation outside our normal view and into third-party infrastructure, we adapted our approach and were honest about it. Transparency, not perfection, is what builds real trust with the research community.
Second, the root cause is rarely simple. In a complex cloud environment, a bug might not live where you think it does. This story isn’t about passing the buck. It is about owning the investigation until the actual source is found, even if that source is a third-party tool. The partnership didn’t fail because the bug wasn’t ours. It succeeded because together, we found the truth.
Partner With Us
Thank you for helping us improve the security of Salesforce products. Partnership with the security community is essential and we value your contributions.
To help our security team address your findings more effectively, we have fully transitioned to a dedicated online portal for all product vulnerability reports. This web-based form is designed to capture all the detailed information our team needs upfront, which helps reduce delays and leads to faster resolution times.
Submission portal: https://www.sfdc.co/SubmitVuln
Please note that the transition period has ended. As of November 15, 2025, the security@salesforce.com email address no longer accepts new vulnerability submissions. We ask that anyone reporting a vulnerability now use the portal exclusively to ensure the most efficient experience.
Salesforce Security Made Simple with Invisibles, Configurables and Enhanceables
Want a fun, approachable way to explain security best practices to your admin and dev networks? Listen to the latest episode of Awesome Admins!
