### Problem to solve Browser-based DAST should have feature parity in terms of passive attacks with Zap, to where we can solely utilize Browser-based DAST for passive scans. ### Proposal To reach parity the following attached rules need to be completed. To see the research status of each rule, view this board: https://gitlab.com/groups/gitlab-org/-/boards/2838631?scope=all&label_name[]=check%3A%3Apassive ### Acceptance Criteria / Scoping Checks can continually be refined and optimized. To avoid working on them indefinitely, we want to tightly scope what is expected of the check for this epic. Follow-on epics will make the acceptance criteria more stringent. - Check must find a vulnerability that our comparison benchmark finds on 1 target application. - Check must report fewer false positives than the comparison benchmark tool. If the false positives are aggregated, then the aggregated count can be used for comparing to the benchmark tool. - Check may report more true positives. - Check does not need to run faster than the comparison benchmark - Checks can be limited to run against the 95% percentile web pages/assets. According to https://almanac.httparchive.org/en/2021/page-weight, the 95% percentile weight of a web page is 6.3mb. Checks can be automatically turned off if a target page/site exceeds that. The engine should log that a target page was skipped and why. - Checks should be able to scan the same mime types as our comparison benchmark (javascript, css, various downloaded files) ### Links and References [Internal Planning Document](https://docs.google.com/document/d/1bzGXFsFXcK8kV2aBMJDv1SgyDzhd_1tff8OOPpgjNSg/edit#heading=h.316ctyeg44fh) ### Links / references [See the Active Attack Parity](https://gitlab.com/groups/gitlab-org/-/epics/5780) <!-- Label reminders - you should have one of each of the following labels if you can figure out the correct ones -->