Security disclosure and testing policy
This policy applies to security researchers interested in our domain,
service and application security. Please read and follow this guideline
when wanting to report security issues.
Testing policy
- Do NOT perform
unsolicited penetration testing on any
of our services. Any such unsolicited testing will inevitably be seen
as an intrusion attempt and reported as such. You may endanger your own
reputation as a security researcher. The fact we publish a security.txt
policy document on our website does not imply permission. See the
relevant section of RFC 9116 about implied permission for testing.
Reporting policy
- Do NOT report
issues that are not security issues (e.g. web content mistakes) to the
security contact e-mail address.
- Do NOT report
"best practices" website issues. The web inherently cannot be covered
by a single, broad-stroke policy applying to any websites, and our
websites are generally explicitly set up the way they are for its
intended audience. This includes reporting "missing website headers"
like
Content-Security-Policy or Strict-Transport-Security
as if that was a security concern that should be addressed immediately.
- Do NOT report
the fact that our public
information is available to the clear web without encryption. Our
websites are accessibility-first, and encryption is used where prudent.
Having parts of our domain available over cleartext is by design. Only report issues where
services should be protected by encryption but erroneously are not.
- When reporting, please provide a rationale why you are
reporting a specific security issue specifically in our domain's
context, taking into account the above points.
- We do not accept anonymous "bot" or scripted reports.
- We do not accept A.I. generated reports. If you are
reporting a real vulnerability, use your real intelligence for it.
- If you want to report a vulnerability in our published
software, please read the relevant
post on our forum.
Responsible disclosure
If you find security vulnerabilities with public impact, please use a
responsible disclosure on your end:
- Provide us with enough time to analyze and patch the
vulnerability.
- Provide us with enough time to publish updated services,
make configuration changes, etc. to mitigate the issue.
- Do not publish
anything yourself in the interim that "paints a bulls-eye on the
target".
- Please discuss with us if you have a deadline for
disclosure on your end, so we are aware of any time pressure that may
be present.
- Please do not give
us deadlines shorter than 30 days for disclosure, even for known
0-days. i.e., don't call attention to our applications, sites or
services being potentially vulnerable unless it has already been
patched.
Security bounties
We do not have a structural
security bounty programme.
Regardless, we will evaluate any legitimate and verified report on a
case-by-case basis to see if the report is eligible for compensation to
the reporter(s). We will take into account many factors, including
timeliness, security impact, affected clients/users, reporting
thoroughness, general communication, background, and internal risk and
impact assessments.
|