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.

Site and contents Copyright © 2009-2026 Moonchild Productions - All rights reserved
Important legal considerations surrounding Pale Moon.
Policies: Cookies - User Content - Privacy.