Docs

Guides

Blog

Tools

Informing Us About Security Issues

To ensure secure handling of security reports, we strongly encourage you to follow the procedures outlined at securitytxt.org. This protocol is designed to help you securely and privately report vulnerabilities.

Why Avoid Direct Plaintext Email?

Submitting security reports via direct plaintext email is not recommended because it lacks the encryption needed to protect sensitive information. Plaintext emails are unencrypted and can be intercepted, exposing confidential details about vulnerabilities before they are addressed. This could lead to unnecessary exposure, putting both our systems and users at risk. Additionally, using plaintext email makes it difficult to control who has access to the information, and it can easily be forwarded or viewed by unauthorized parties. For these reasons, we strongly encourage the use of secure communication methods like encrypted email or the reporting tools specified in our security.txt file.


By following these guidelines, you help ensure that your report remains confidential, reducing the risk of exposure and enabling us to act swiftly and responsibly. Thank you for helping us maintain a secure environment!


If your discovery reveals a high-severity vulnerability and includes a tangible proof of concept (PoC) that demonstrates a real impact on our operations, we would be glad to show our appreciation by offering you our products or exclusive discount codes.

However, if your report is based solely on the use of automated tools to identify low-risk issues, and you are seeking financial compensation, please note that this site does not operate a bug bounty program for such findings.

Examples of issues that are not considered valid security reports:
  • Misconfigured DNS records (e.g., DMARC, SPF, DKIM warnings)
  • Missing or optional HTTP security headers (e.g., X-Frame-Options, X-XSS-Protection, Content-Security-Policy)
  • Clickjacking on public or non-sensitive pages
  • Information disclosures that do not involve personal or sensitive data (e.g., server version, technology stack)
  • Lack of rate limiting on login or search forms that do not handle sensitive actions
  • Use of outdated libraries or components without a known exploit or relevant context
  • Debug or verbose error messages on staging or development environments
  • Open directories or listing pages without sensitive content
  • HTTP to HTTPS redirection findings
  • Presence of .gitignore, robots.txt, or similar configuration files
  • Publicly accessible analytics or monitoring endpoints without sensitive data
  • Self-signed or expired certificates on non-production domains
  • TLS/SSL configuration issues that do not pose real-world risks
  • Subdomain takeovers that are not exploitable or affect unused subdomains

We encourage researchers to focus on vulnerabilities that could lead to unauthorized access, data exposure, privilege escalation, or other meaningful security impacts.