Salesforce security review checklist: wat je oplost, en in welke volgorde

De meeste AppExchange-inzendingen sneuvelen op een korte, voorspelbare lijst, en toegangscontrole staat bovenaan. Werk deze checklist op volgorde af, eerst afdwingen van toegang in user mode, dan het triageren van scannerbevindingen, dan het inzendmateriaal, en je haalt de meeste redenen weg waarom een reviewer een package terugstuurt. Salesforce houdt 4 tot 5 weken aan voor een review, dus een afwijzing kost je een release-cyclus en niet een middag.

Tekunda heeft managed packages door de AppExchange security review geloodst in de zorg, logistiek en maakindustrie. Wat hieronder staat is de volgorde waarin wij werken, geen beschrijving van het proces.

Waarop wordt een Salesforce security review afgewezen?

Werk van boven naar beneden. De bovenste punten zijn tegelijk de meest voorkomende bevindingen en het duurst om achteraf in te bouwen, en juist daarom kost het uitstellen ervan een hele cyclus.

1. Toegangscontrole die niet in user mode wordt afgedwongen. Elke query en elke DML-actie in je package moet de objectrechten, veldbeveiliging en sharing van de ingelogde gebruiker respecteren. Kies WITH USER_MODE bij SOQL en AccessLevel.USER_MODE bij Database-aanroepen boven zelfgeschreven isAccessible()-reeksen, die snel onvolledig blijven.
2. Sharing op de verkeerde klassen gezet. Een Apex-klasse zonder sharing-keyword erft de sharing van de aanroeper, dus een helper die vanuit een @AuraEnabled-methode wordt aangeroepen kan er ongemerkt zonder draaien. Zet with sharing expliciet op elke klasse, ook op inner classes en utility classes.
3. Dynamische SOQL die uit invoer wordt opgebouwd. Gebruik bind variables. Moet een query echt als string worden gebouwd, escape dan elke ingevoegde waarde en houd dat escapen zichtbaar in dezelfde methode, want daar leest een reviewer het.
4. Output zonder escaping. Alles wat via escape="false", lwc:dom="manual" of innerHTML op de pagina komt, moet daarvoor al gesaneerd zijn, niet erna.
5. Secrets en klantdata op de verkeerde plek. Hardcoded sleutels in Apex, tokens in custom settings, een record met persoonsgegevens dat via System.debug gaat. Named Credentials en protected custom metadata zijn wat reviewers in plaats daarvan verwachten.
6. Externe endpoints die niemand gescand heeft. Roept je package een dienst aan die jij zelf draait, dan valt die dienst binnen de scope en heeft die een eigen dynamisch scanrapport nodig.
7. Een testomgeving die de reviewer niet kan gebruiken. Een verlopen org, een identity challenge die hem buitensluit, of objecten zonder data. Het team gebruikt je oplossing end to end zoals een klant dat zou doen, en kan niet beoordelen wat niet draait.

Welke scannerbevindingen zijn false positives, en hoe documenteer je ze?

De lat ligt niet op nul bevindingen, en hij ligt per scanner anders. De voorbereidingsrichtlijn van Salesforce zelf zet het uiteen:

• Salesforce Code Analyzer: los elke security-gerelateerde fout op en negeer bevindingen die niet over security gaan.
• Source scan van het Partner Security Portal: los Low, Medium en High op en laat informational warnings staan.
• Dynamische scanners zoals ZAP, Burp Suite, Veracode, Intruder, Acunetix en JiT DAST: los alles op behalve informational items en warnings, en voeg een screenshot toe dat bewijst dat het juiste endpoint is gescand.

Sinds Salesforce de gehoste Chimera-scanner op 2025-06-16 stopte, draai je die dynamische scan zelf. Zie Je eigen dynamische scans draaien na Chimera voor de geaccepteerde tools en het rapport dat je inzendt.

In onze inzendingen komen vier categorieen vaak genoeg terug als echte false positive om er rekening mee te houden: toegangscontrolebevindingen op code die user mode al afdwingt, sharing-bevindingen op klassen die alleen worden binnengekomen via een context waarin sharing al is toegepast, retired-library bevindingen die matchen op een versienummer in een meegeleverde static resource, en reflected cross-site scripting op parameters die de DOM nooit bereiken.

Gelijk hebben is alleen niet genoeg. Het document is wat je erdoor helpt. Salesforce vraagt om een document dat uitlegt waarom elk gemarkeerd item geen beveiligingsrisico vormt, en zegt erbij dat je specifiek moet zijn over hoe je je beschermt tegen de aangegeven kwetsbaarheid. Geef elke bevinding een eigen regel: scanner en regel-id, bestand en regelnummer, een zin over het datapad, de precieze maatregel die het afdekt, en waar die maatregel in het package staat. Afdoen in een halve zin komt terug als een vraag, en vragen kosten weken. Voor een uitgebreide uitleg van het onderbouwingsformat en de fouten die het laten afkeuren, zie False positives documenteren voor de Salesforce security review.

Wat gaat er naast het package mee in de inzending?

• Gebruikersdocumentatie die zo geschreven is dat iemand die de app nooit heeft gezien een volledige workflow kan doorlopen.
• Documentatie van de datastromen tussen de Salesforce-org en elke composite site, mobiele app of browserextensie.
• Alle scanrapporten, plus het false-positive document.
• Een Developer Edition org met het package geinstalleerd en realistische testdata.
• Inloggegevens voor elk extern systeem dat de app raakt, inclusief API-, OAuth- en SAML-toegang.
• Installatielinks en inloggegevens voor eventuele mobiele of desktopclients.

Hoe lang duurt de security review, en wat kost hij?

Salesforce geeft aan dat een oplossing doorgaans 4 tot 5 weken door de review doet, en dat voor elke betaalde oplossing op de marketplace een fee van $999 geldt voor de eerste inzending en voor elke volgende poging. Beide feiten wijzen dezelfde kant op: doe het werk aan toegangscontrole vooraan, want de goedkoopste inzending is de inzending die je maar een keer hoeft te doen.

Verpak je een product en laat je de review liever over aan mensen die er al doorheen zijn gekomen? Tekunda bouwt en verpakt AppExchange-producten als Salesforce PDO.

FAQ

Moeten gratis apps ook door de security review?

Ja. Elke oplossing die op de marketplace wordt gedistribueerd moet de review doorstaan voordat hij wordt gepubliceerd. De fee die Salesforce documenteert geldt voor betaalde oplossingen.

Is Salesforce Code Analyzer op zichzelf genoeg?

Nee. Code Analyzer v5 dekt de Apex, Visualforce, JavaScript en TypeScript in je package. Elk extern endpoint dat je app aanroept heeft daarnaast een eigen dynamisch scanrapport nodig.

Wat is de meest voorkomende reden voor afwijzing?

Toegangscontrole. Queries en DML die in system mode draaien, en klassen die sharing erven in plaats van het te declareren, leveren meer bevindingen op dan wat dan ook.

Verandert een Agentforce- of agent-app de checklist?

Voor agentic oplossingen geldt dezelfde security review. Het verschil zit in de documentatie van de datastromen, want elke externe dienst die je agent kan aanroepen moet beschreven en gescand zijn.