What Is a Web Application Scanner, and Which One the Salesforce Security Review Needs

If your Salesforce integration calls servers you run, the security review expects a web application scanner report on those servers, and you pick the scanner. Salesforce asks for a DAST (dynamic application security testing) scan of every external endpoint, "such as ZAP, Burp Suite, HCL AppScan or WebInspect." The Chimera scanner that older guides send you to no longer appears in the current security review documentation. A package that never leaves Salesforce needs no DAST report at all.

For a SaaS company, the DAST report is the part of review that tests your own product rather than the package. The native integration enterprise customers asked for calls your API, sends users through your login, and moves Salesforce data to your servers. All of that is in scope. You build the package, pass review, publish the listing, then rerun the scan whenever you fix something an endpoint was flagged for. Appnigma's marketplace apps service covers this path, with "Salesforce security review preparation and responses" included. If you came for a general list of web vulnerability scanners rather than the Salesforce review, OWASP's scanning tools list is the place to start.

Updated October 2026. Checked against the Salesforce ISVforce Guide and the ZAP and Burp Suite documentation. The earlier version pointed to Chimera, said Burp Suite always needs a paid license, and said these tools ensure you meet Salesforce's standards. This update removes Chimera and corrects the Burp Suite editions. It also adds when the report is required, how Salesforce wants the scan run, and which findings you must fix.

When does the security review need a DAST report?

Salesforce decides it by solution type, and the Required Materials page spells it out by solution type.

Most SaaS integrations sit in the second row. A managed package that calls your backend through a Named Credential is a native package with an external service, so you submit both the static scan and the DAST reports. For managed packages the static side has changed too. The Test Your Entire Solution page says "you're required to scan it using Salesforce Code Analyzer." Neither Code Analyzer nor the Source Code Scanner touches your servers. The docs say plainly that Code Analyzer "doesn't scan external endpoints," and that gap is what the DAST report fills.

Which of your hosts count is decided by a "follow-the-data approach." An endpoint is in scope when it "plays a role in authenticating the end user" or when "Salesforce data is transferred to or from the endpoint." That includes "a connected app that doesn't require manual credential entry," so an OAuth flow your package runs behind the scenes still puts your token endpoint in scope. Our Qualys SSL scan guide walks through building the hostname list, which is the same list your DAST scan needs.

Which scanner to use now that Chimera is gone

Chimera was the hosted DAST scanner Salesforce used to run for partners, and it has been retired. The Partner Security Portal FAQ says "Salesforce WILL NOT provide any support for Chimera DAST scans after June 16, 2025." The current Source Code Scanner page replaces that with a choice. It says to "use any Dynamic Application Security Test (DAST) scanner that you prefer." The Partner Security Portal hosts only the Checkmarx static scanner now, so the DAST tool and its license are yours to pick.

The row that trips teams up is Burp Suite Community Edition. It is free, but its automated scanner isn't included, so it can't produce the full scan report Salesforce asks for by itself. For most SaaS teams ZAP is the practical default. It is free, scriptable and runs headless in a container. Burp Suite Professional earns its cost when someone on your team will also test by hand.

How to run the scan the way Salesforce describes it

Salesforce's scanner table describes a proxy workflow, and following it closely is what makes the report usable.

You route your API client or browser through the scanner's proxy, then exercise every endpoint while it records, including the calls your package makes. Next you run an active scan against what was recorded and fuzz requests by hand for deeper testing. The last step is to "Export a full report after the scan, including the scan date, targeted endpoints, and all findings."

The recording step is where SaaS scans most often fall short. The endpoints that matter are the ones your package calls after a customer connects, and a crawler that only sees your marketing site never reaches them. If your API is described by an OpenAPI file, ZAP's API scan imports the definition and runs an active scan "tuned to APIs" against every URL in it. That tuning cuts both ways. The same page says it "doesn't bother looking for things like XSSs," so any host that serves HTML, such as your login page or an embedded app page, needs a regular full scan as well.

docker run -v $(pwd):/zap/wrk/:rw -t ghcr.io/zaproxy/zaproxy:stable \
  zap-api-scan.py -t https://api.example.com/openapi.json -f openapi \
  -r dast-report.html

That run is unauthenticated, so it tests only what an anonymous caller can reach. Most of an integration API sits behind a token. ZAP's -n option loads a context file and -U names the user from that context, which lets the scan run as a logged-in caller. Scan the environment you will give reviewers, and run the scan close to submission, because the report has to carry its scan date.

If a host belongs to someone else, such as a messaging or payment API your product relays Salesforce data through, stop before scanning it. Salesforce says to first "obtain any necessary permission to perform security testing from the third parties that own the external endpoints." Our guide to third-party APIs in an AppExchange app covers how those dependencies show up in review.

Which DAST findings you have to fix

Not every finding blocks review. Salesforce's false positives page sets the line for "ZAP, Burp Suite or any other DAST scanner" at "Issues categorized as critical and high-severity." For low and medium findings, it says "Action on low and medium severity issues isn't required, but investigation into whether they pose a security threat is encouraged."

ZAP has no critical level. Its alert docs give every alert a risk that is "One of: Informational Low Medium High," so in a ZAP report the line Salesforce draws means every High alert. Fix each of those, or document why it is a false positive. Trailhead's security review prepare unit sets a stricter bar for DAST tools, "All findings except those listed in the next column," which are informational issues and warnings. The safe plan for a first submission is to fix or document every High and Medium alert, so neither reading sends you back. Write the false positive document to name the finding, the endpoint, and why it can't be exploited, because reviewers read it next to the report. Leave mediums and lows in the report rather than filtering them out, since Salesforce asks for "all findings." A short note on the ones you looked at shows the diligence the Required Materials page asks for, where Salesforce says "We like to see that you did your due diligence."

A clean report doesn't mean a pass. The same Test Your Entire Solution page says reviewers "can perform pen tests that attack your Developer Edition test org." The scan is your evidence, and the review team still tests on its own. A recent penetration test can stand in for the scan. The Partner Security Portal FAQ adds that "Salesforce requires full pentest results, not summaries." If they send the submission back over an endpoint, the follow-up review page asks for "updated Dynamic Application Security Test (DAST) scan reports," so plan on running the scan again after every fix.

Mistakes that get a DAST report sent back

These come up on SaaS submissions and each one costs a review cycle.

• Scanning the marketing site. The API, login and callback hosts carry the Salesforce data, and they often run on separate infrastructure.
• An unauthenticated scan of an authenticated API. The report shows almost nothing because the scanner was turned away at the door.
• A Burp Suite Community export as the DAST report. It has no automated scanner, so it can't show an active scan.
• Trimming the report to the findings you fixed. Salesforce asks for all findings, and a filtered report looks like missing evidence.
• An SSL Labs grade in place of the scan. A TLS grade is not a DAST report, and Qualys isn't among the scanners Salesforce names. Our Qualys SSL scan guide covers where that grade fits.
• Scanning a third-party host without permission. Salesforce asks for the owner's permission first, and some providers treat an unannounced scan as an attack.
• A scan from months ago. Reviewers see the date, and anything you shipped since then is untested.

Frequently Asked Questions

Is a DAST scan required for the Salesforce security review?

Only if your solution connects to a non-Salesforce domain. Then the Required Materials page lists DAST scan reports for external web apps, mobile clients, API-only and Marketing Cloud solutions.

Is the Salesforce Chimera scanner still available?

No. Salesforce ended Chimera support in June 2025. It now says to use any DAST scanner you prefer, such as ZAP, Burp Suite, HCL AppScan or WebInspect.

Can I use ZAP instead of Burp Suite for the security review?

Yes. Salesforce names both, and ZAP's free automated scan produces a full report with the scan date, endpoints and findings.

Do I have to fix medium DAST findings?

No. Critical and high findings need a fix or a false positive explanation. Salesforce encourages you to investigate mediums and lows but doesn't require action.

Can Appnigma help us get through the security review?

Yes. Appnigma's marketplace apps service includes "Salesforce security review preparation and responses" alongside building the native app. Approval timing stays with Salesforce.

About the author

Sunny Chauhan is the co-founder and CEO of Appnigma AI, which builds and maintains customer integrations and native Salesforce and HubSpot apps for B2B SaaS teams. Before Appnigma, he was on Salesforce's AppExchange team, where he worked with more than 300 SaaS partners. He has spent close to a decade on the Salesforce platform, including work at Zennify, and holds Salesforce certifications including Platform Developer II, Platform App Builder, Administrator, Data Cloud Consultant, and AI Associate.

Related Articles

• The Salesforce security review guide for SaaS teams
• What a Qualys SSL scan checks before security review
• Salesforce Code Analyzer for managed packages
• The Salesforce Source Code Scanner explained
• The AppExchange security review, step by step
• Salesforce security review checklist

Sources

1. Salesforce Developers, ISVforce Guide, Source Code Scanner on the Portal
2. Salesforce Developers, ISVforce Guide, Test Your Entire Solution
3. Salesforce Developers, ISVforce Guide, Required Materials for Security Review Submission
4. Salesforce Developers, ISVforce Guide, Document Your Responses to False Positives
5. Salesforce Developers, ISVforce Guide, Submit Your Solution for a Follow-Up Security Review
6. ZAP, API Scan
7. ZAP, Baseline Scan (Docker usage)
8. PortSwigger, Burp Suite Community Edition
9. PortSwigger, Burp Suite Professional
10. Salesforce Partner Security Portal, FAQ (Chimera Sunset and DAST Scan)
11. Trailhead, ISV Security Review, Prepare for the Security Review
12. ZAP, Alerts
13. OWASP, Vulnerability Scanning Tools