Key Takeaways
Voor vertrouwen is meer nodig dan sterke technologie. Productbeveiliging vraagt om transparantie, samenwerking en de bereidheid om elk signaal serieus te onderzoeken. Dat geldt voor Salesforce, voor onze klanten en voor de wereldwijde community van beveiligingsonderzoekers. Voor klanten laat dit verhaal zien hoe zorgvuldig we omgaan met mogelijke dreigingen. Voor beveiligingsonderzoekers laat het zien hoe belangrijk hun werk is.
Beveiligingsonderzoekers volgen aanwijzingen, testen grenzen en melden wat ze ontdekken. Maar een beveiligingsonderzoek stopt niet bij een rapport. Het draait om het vinden van de echte oorzaak, ook als het onderzoek een onverwachte wending neemt. Deze casestudy laat zien hoe diep we graven, omdat grondig onderzoek een belangrijk onderdeel is van een veilig en betrouwbaar platform.
De melding: een plausibele dreiging
Ons onderzoek begon met een melding over een mogelijke serviceonderbreking op een van onze e-commerceplatforms. De melding beschreef hoe een ongewoon groot en specifiek geformatteerd verzoek naar het systeem kon worden gestuurd. Daardoor zou het platform kunnen vertragen of tijdelijk niet meer reageren.
Tijdens de test van de onderzoeker verscheen na ongeveer 60 seconden een vertraagde foutmelding. Volgens de onderzoeker wees dit erop dat er onvoldoende systeemresources beschikbaar waren en dat onze systemen het verzoek niet goed blokkeerden
Wat het onderzoek liet zien
Uit onze eerste evaluatie bleek dat onze beveiligingsmaatregelen aan de netwerkrand naar behoren werkten. Het grootste deel van de ongeldige verzoeken werd correct geweigerd met de standaard foutmelding 413 Payload Too Large. Op basis daarvan dachten we eerst dat de onderzoeker waarschijnlijk te maken had met een lokaal probleem of een verbindingsspecifieke situatie, en niet met een breder risico voor de beschikbaarheid van het platform.
Maar de onderzoeker bleef volhouden en legde duidelijk uit hoe de time-out van 60 seconden opnieuw kon worden geactiveerd. Dat liet zien hoe belangrijk samenwerking met de onderzoekscommunity is. Met gedetailleerde informatie van beveiligingsonderzoekers kunnen onze teams de exacte omstandigheden van een mogelijk probleem nabootsen. Dankzij die extra informatie konden we onze testparameters uitbreiden.
Onze technici voerden de test opnieuw uit. En inderdaad: het systeem bleef precies 60 seconden hangen. De onderzoeker leek dus gelijk te hebben. De bug bestond en leek zich op ons platform te bevinden. We lieten weten dat we aan een oplossing werkten. Maar toen we onze logboeken verder onderzochten, veranderde het beeld. Het antwoord zat niet in de code, maar in het netwerkverkeer.
De echte oorzaak kwam aan het lichtkking
We zagen dat er iets ontbrak. De time-outreacties hadden niet de standaard trackingkenmerken die we aan elk verzoek toevoegen. Dat was een belangrijke aanwijzing. Het betekende dat het verzoek onze applicatie nooit had bereikt.
In plaats daarvan vonden we een onbekende vingerafdruk: de header x-geoptimaliseerd-door van een externe partij.
De onderstaande afbeelding laat zien welke route het verzoek daadwerkelijk aflegde:
Het verzoek liet onze servers dus niet crashen. Het was al veel eerder in de keten blijven hangen, bij een controlepunt buiten onze applicatie. Het probleem zat niet in ontoereikende systeemresources, maar in een standaard time-outinstelling op een proxyserver die we niet beheren.
Wat we uit dit onderzoek leerden
Dit onderzoek laat twee belangrijke dingen zien over moderne cloudbeveiliging.
Ten eerste is de waarheid niet altijd meteen zichtbaar. We volgden het bewijs, ook toen het leek alsof de fout in onze eigen systemen zat. Toen het bewijs naar externe infrastructuur wees, pasten we onze aanpak aan. Daar waren we ook open over. Want vertrouwen ontstaat niet door perfectie, maar door transparantie.
Ten tweede is de onderliggende oorzaak in een complexe cloudomgeving zelden eenvoudig. Een probleem kan zich ergens anders bevinden dan waar het zichtbaar wordt. Daarom is het belangrijk om te blijven onderzoeken totdat de echte bron is gevonden, ook als die bron een externe tool blijkt te zijn.
Dit verhaal gaat niet over verantwoordelijkheid afschuiven. Het gaat over zorgvuldig onderzoek en samenwerking. De samenwerking bleef sterk, juist omdat we samen ontdekten wat er echt aan de hand was.
Help mee aan betere productbeveiliging
Bedankt dat je ons helpt de beveiliging van Salesforce producten te verbeteren. Samenwerking met de beveiligingscommunity is essentieel en we waarderen je bijdrage.
Voor kwetsbaarheidsrapportages over onze producten gebruiken we nu een speciale online portal. Zo kan ons beveiligingsteam je bevindingen sneller en effectiever beoordelen. Het webformulier verzamelt vooraf alle informatie die ons team nodig heeft. Dat voorkomt vertraging en helpt ons sneller tot een oplossing te komen.
Raportageportal: https://www.sfdc.co/SubmitVuln
Let op: de overgangsperiode is afgelopen. Sinds 15 november 2025 accepteert security@salesforce.com geen nieuwe kwetsbaarheidsrapportages meer. Meld kwetsbaarheden daarom uitsluitend via de portal, zodat we je melding zo efficiënt mogelijk kunnen behandelen.
Salesforce-beveiliging is eenvoudiger met Invisibles, Configurables en Enhanceables
Wil je een interessante, toegankelijke manier om best practices op het gebied van beveiliging uit te leggen aan je beheerders- en developersnetwerken? Luister naar de nieuwe aflevering van Awesome Admins!
