Responsible Discosure Policy

As a security company, we know we are held to high security standards. We value our security community and welcome input regarding security vulnerabilities that may be found in our systems. We encourage researchers to inform us of any vulnerabilities they may find in our system using the process set forth below. 

PLEASE NOTE: Disclosures that do not conform to this process may not be eligible for bug-bounty awards. 

Reporting Security Issues

If a security vulnerability is discovered with DNSFilter’s services or website please email

What you can expect from us:

  • We will acknowledge receipt of your report within 5 business days. 
  • We will internally review the reported issue to confirm validity. 
  • If at this time we have any questions or need more details we may engage you. 

What we expect from your report:

  • A description of the type of issue (e.g. SQL injection, Cross-Site Scripting, etc.)
  • Your perspective on the impact, criticality, and any abuse cases.
  • Sample code, proof-of-concept, and/or tool used to generate exploit
    • If we don’t have access to a specific tool and can’t replicate the issue we might reach back for further proof
  • Any HTTP requests, responses, code snippets, or other evidence to help with reproduction.
  • Any information you may have accessed during testing. If the information could be considered sensitive in any way please redact the information so that it is not identifiable.  

Professional Expectations

  • Partner with integrity and transparency  
  • Do not disrupt, modify, or destroy any other customer’s data, DNSFilter data, or our services
  • No brute-force attacks or social engineering (further details provided in the “Out-of-Scope Items” section). 
  • If public disclosure is intended, we ask that the timeline be coordinated and agreed upon with DNSFilter and the researcher in advance of any such disclosure.

Bug Bounties

DNSFilter will reward researchers who responsibly disclose vulnerabilities with awards tiered in accordance with our assessment of the vulnerability risk level. 

Bounty Schedule

This is approximately how much we expect to pay for reports. Understand that this is a guide — it is meant to help set expectations and is not a guaranteed payout amount.

  • "not applicable" — out of scope issues
  • "informative" — we are aware of this, or we do not see it as a security issue
  • $250 — A minor security problem that we will fix on our schedule based on planning
  • ≤$750 — A medium security issue that we will work on getting fixed in a timely manner based on our other work priorities 
  • $1000 and beyond — A high-severity issue that needs to be prioritized for remediation and makes a significant impact on DNSFilter’s security posture

Most bounties awarded by us are between $250 and $500. Only a handful of issues ever have qualified for a bounty payment of $1,000+.

Bounty Rules

  • When duplicates occur, we award the first report that was received.
  • Multiple reported issues that are caused by one underlying problem will be awarded one bounty.
  • In the event of any disagreement with respect to bounty awards and/or amount, any decision from the DNSFilter Security Team is final.

In-Scope Properties

Our Bug Bounty program applies to the following properties :

  • *
  • *
  • All DNSFilter Roaming Clients

Out-of-Scope Properties

Our Bug Bounty program specifically excludes the following properties:

  • *

Third-Party Bugs

If issues reported to our bug bounty program affect a third-party library, an application, or another vendor, we reserve the right to forward details of the issue to that party without further notice. We ask the researchers to comply with the third party’s vulnerability disclosure or bug bounty program.

Out-of-Scope Items

Our Bug Bounty program DOES NOT cover the following items: 

  • Findings derived from social engineering (e.g. phishing, vishing, etc).
  • Raw output from common network and vulnerability scanning tools
  • Functional, UI, and UX bugs and spelling mistakes.
  • Denial of Service (DoS/DDoS) vulnerabilities
  • Clickjacking or missing security headers (i.e. HSTS, CSP, x-frame-options)
  • Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions
  • Attacks requiring MITM or physical access to a user's device.
  • Previously known vulnerable libraries without a working Proof of Concept.
  • Missing best practices in SSL/TLS configuration.
  • Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
  • Rate limiting or bruteforce issues on email or API endpoints
  • Missing best practices in Content Security Policy.
  • Missing HttpOnly or Secure flags on cookies
  • Any session staying active after a user makes an update to their account (i.e. password update, email change, 2FA change, phone number change, etc)
  • Missing security controls, configuration best practices or business logic issues without a working proof of concept
  • Missing email best practices (Invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)
  • Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]
  • Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, garbage collection, application or server errors).
  • Public Zero-day vulnerabilities 
  • Tabnabbing
  • Self-XSS
  • Open redirect - unless an additional security impact can be demonstrated
  • Issues that require unlikely user interaction