API Scanning

the scanmode=apiscan option loads a ruleset that is tuned for performing scans against openapi , soap , or graphql apis api scanning combines both passive rules and active rules, meaning common misconfigurations and vulnerabilities will be located using the passive ruleset, as well as actively trying to attack the endpoints using the active ruleset soos recommends running as the zap user (1000 1000) but this user will need rwx access to the mount in the examples below if you can't do that, you may run without the u parameter and have the container run as root but this is not recommended unless absolutely necessary run a passive only api scan active api scans can take significant time to run, especially for larger apis, therefore running these scans frequently is not always possible however, performing frequent ci/cd scans against apis is achievable by only running the passive api ruleset this will not catch all the issues that an active scan will, however it can be a great baseline verification of the api after each commit or deploy use the otheroptions=" s" parameter to run only the passive ruleset scanning apis using openapi spec files there are two options for scanning apis using an openapi spec file, either pass the url of the spec file or point to a local spec file scanning a hosted openapi spec file often openapi spec files are deployed with the apis they are defining as long as the spec file is available, it's easy to scan directly from the hosted location if the server url in the spec file needs to be updated, this can be accomplished by passing the otheroptions=" o 'https //new server url'" parameter, otherwise simply omit this parameter if the hosted spec file requires authentication, refer to running authenticated dast scans docid 0wmgc4eqb 1saulseahnt for example use request header authentication by including the requestheaders parameter scanning a local openapi spec file hosted openapi spec files are not always available, or it may simply be easier to grab the spec file from a previous step in a build process an additional advantage of scanning a local spec file is that, the server url(s) and/or api endpoint paths can be updated this option works even if the spec file isn't available locally, by using a tool such as curl to download the spec file, then using a tool such as jq to modify the json, before passing the local file to the dast cli the following example scans a local spec file my spec file json (assuming the server url is correct or has previously been updated) further configurations running authenticated dast scans docid 0wmgc4eqb 1saulseahnt excluding dast scan rules docid 1hh1sr62 gxmfmneie6g adjusting scan times docid\ vizjose7ku 8zlrqxt2br