Whatbox Logo

Security Policy > whatbox.ca

This page provides scope and reward information for this portion of our bug bounty program, please see the Security policy for general rules if you haven't already.



We are not currently providing rewards for the following types of vulnerabilities:

  1. Denial of service.


Your cash reward is the largest single value your exploit can be categorized under in the following table. Whatbox customers may ask to receieve a service credit instead of cash.

Rewards are paid out exclusively via PayPal at this time./

Category Cash Service credit
XSS 300 USD 1,200 USD
XSS (bypassing CSP) 2,000 USD 8,000 USD
CSRF 600 USD 2,400 USD
Authentication bypass 1,500 USD 6,000 USD
SQL Injection 12,000 USD 48,000 USD
Arbitrary code execution 4,000 USD 16,000 USD
Arbitrary code execution (with privilege escalation) 15,000 USD 60,000 USD
Persistent code change 10,000 USD 40,000 USD

Recently rejected

No CSRF token on /logout

While the lack of a CSRF token means an attacker can trick a user into logging out of their Whatbox account, we consider this a non-issue.

  1. A cross site logout increases the security of the user, by restricting the potential for further exploit.
  2. If CSRF tokens were employed, an expired token could prevent a user from logging out successfully and accidentally leaving a valid session open when they intentionally clicked "Logout".
Username or email enumeration (with rate limit)

Due to the requirements for unique usernames and unique email addresses, username enumeration is possible in many areas of the site. We employ rate limiting to limit the volume of information that can be leaked this way.

Host header injections

We do not consider this a real vulnerability.

An attacker cannot make a victim's browser submit an invalid Host header without directly controlling the browser / computer which forms the trusted computing base for a website. If the attacker already has this much control, no counter-measure can keep a potential victim safe.

Some researchers have pointed out that some websites use the Host value in generated page content. We don't use the Host value in our code, preferring domain relative URLs (eg. /preferences).

Unless you can construct a HTML proof of concept that triggers this in an unmodified web browser, we will reject all reports of this type.

No password complexity rules

This is more subjective than most of our security choices. The composition of passwords has been an ongoing debate for several years, and we fall into the camp that believes in allowing as many types of passwords as possible.

People don't want the cognitive load of remembering more complex passwords, so if you require lower + upper + number they will change their password from "password" to "Password1" which is not much better.

A password that consists entirely of lowercase letters or only numbers can still be stronger (more entropy) than one with uppercase letters, symbols, etc. simply due to length. Passwords of any length can also be useless if they're reused across many websites and become known to an attacker.

We have experimented with the haveibeenpwned API in the past. This denylist can catch all passwords known to attackers (and would statistically block all the easy ones like "123456"). Unfortunately, we have refrained from deploying this because people find it upsetting when you tell them their password is known to blackhat attackers.

For some of the discussions we've watched over the years:

We feel the best hope for the future of password security is built-in browser password managers, like Chrome's efforts to generate unique random passwords for every website.

We also intend to implement biometric based logins for supported devices, helping users use strong, unique identifiers with minimal cognitive load.

An account that nobody knows the password to is the most secure of all, but it's not very useful to anyone. We need to balance the need for high entropy unique passwords against unreliable human memory.


DNSSEC has been on our radar for several years, but we remain concerned about the impact on reliability.

DNSSEC looks like a "footgun" to us.

Similar to HTTP Public-Key-Pinning before it, it does provide a security improvement, but has a very unforgiving implementation where the slightest human error can cause outages that are impossible to resolve. There's no "undo" with DNSSEC, and it frequently brings major domains offline for weeks at a time.

We intend to wait this one out several more years. I believe either DNSSEC will be replaced by a v2 that addresses some of the pitfalls or the combined experience of many engineers across many organizations will create a well documented set of best practices we can follow.

For reference, here is an incomplete list of major outages caused by DNSSEC.