Skip to main content

Vulnerability disclosure policy

If you have found a security vulnerability in Hook0, we want to hear about it. This page tells you what we consider a vulnerability, how to report one, and what happens next.

Scope​

The Hook0 API is in scope. That means app.hook0.com/api, and the same API in a self-hosted deployment, since both run the same code. Reports about authentication, authorization, tenant isolation, token handling and webhook signature verification are the ones we care most about.

Everything else is out of scope:

  • The marketing site (www.hook0.com), the documentation site (documentation.hook0.com) and the webhook testing playground (play.hook0.com).
  • How third-party software renders our output. Mail clients that turn text into clickable links, browser autofill, and PDF readers are outside our control.
  • Findings from an automated scanner with no working proof of exploit.
  • Missing hardening headers, TLS configuration preferences, missing SPF or DMARC on domains that send no mail, and other findings with no demonstrated impact.
  • Social engineering, physical access, denial of service, and volumetric or rate-limit testing against production.
  • Anything that requires you to already control the account or the endpoint, including self-XSS.
  • Content you submit through a public form that is then rendered back to you, or to an address you chose yourself.
  • Configuration of a self-hosted deployment: an exposed database, secrets in plaintext, or a misconfigured reverse proxy is the deployer's responsibility, not a flaw in Hook0.

Known and accepted​

Some findings are real, get reported again and again, and are already settled. Sending one is welcome and will not change anything, so it is fairer to say which they are than to let you spend an evening on them.

  • The cipher suites built on CBC with a SHA-1 MAC, on the hostnames served through our CDN. We keep TLS 1.2, and those suites come with it, because customer integrations still depend on it and we will not stop them at the handshake to improve a scan result. What we measured, what holds alongside it and what does not are on the security page.

Two researchers reported that one before this section existed, and both are credited on the acknowledgments page. The entry is here so the next person can spend their time on something we do not already know about.

What we reward​

We may offer a reward, at our discretion, for a critical vulnerability in the in-scope API. Critical means a remote attacker can read or modify another tenant's data, take over another user's account, or execute code on Hook0 infrastructure.

There is no published payment scale and no automatic entitlement. Reports that fall outside that definition are still welcome and still get fixed, and we would rather know about them, but they are not rewarded.

How to report​

Email [email protected]. You can encrypt with our PGP key.

Send us enough to reproduce the issue: the affected endpoint, the steps, and a working proof of concept. Reports without a reproducible proof of concept take much longer to assess, and some cannot be assessed at all.

We acknowledge reports as soon as we can. We are a small team, so we do not publish a response deadline we might miss.

Rules​

Test against your own account and your own data. Do not access, modify or store another user's data. If you stumble onto someone else's data, stop and tell us what you saw.

Do not run automated scanners against production, and do not test availability.

Give us time to ship a fix before publishing. We will tell you when the fix is out, and we are happy to coordinate the timing with you.

The first person to report a given issue is the one we work with.

After the fix​

We publish a security advisory for vulnerabilities that affected users, and we credit the reporter by name in it unless they prefer otherwise. Every researcher whose report we act on is also listed on our security acknowledgments page, whatever the severity of the finding.