The ZAP scan should be tunable based on features of the target site. about concourse-compliance-testing

[afeld]

@konklone Can you elaborate a bit on what sort of configuration changes you'd like to make?

[konklone]

For all of our sites, I'm not a fan of us using a threat model that tries to mitigate users' computers which have been owned. That's what the browser cache-related flags are about.

For static sites that have no capacity to receive or act upon user input, we should consider de-scoping some of the "security headers" flags. I think it will require more conversation than this thread to consider whether or not X-XSS-Protection can possibly be relevant to a static site, but if it's going to come up in scans for sites which may have no way to easily remediate them (e.g. S3/CloudFront combo sites), we should try to be thoughtful.

I also requested that dap.digitalgov.gov be given special treatment in some way when flagging third party services, since government sites are encouraged to use it and it's not as much of a "third" party as the other services it detects. Same for search.usa.gov. It looks like the scanner already doesn't bring up Google Analytics. We should confirm that that's deliberate and that we agree with it (I do).

For some common third parties, like Google Fonts, it would be helpful to link to specific remediation examples, like this one.

In general, I think the success of these scanning efforts will be tied closely to how high-signal they are to development teams. Those doing the scanning should try to make each flagged item as relevant, justified, and easy to fix as possible.

[afeld]

consider whether or not X-XSS-Protection can possibly be relevant to a static site

Cool, that's the kind of stuff I was looking for.

I also requested that dap.digitalgov.gov be given special treatment in some way when flagging third party services

👉 #76