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. Published advisories are collected on our security advisories page.

CVE identifiers​

Hook0 runs the same code on app.hook0.com and in a self-hosted deployment, so a vulnerability in that code affects both. For a finding that warrants one, we request a CVE through GitHub Security Advisories, where GitHub acts as a CVE Numbering Authority. We draft the advisory privately on github.com/hook0/hook0, request the identifier there, and publish it the day the fix ships, with the reporter credited. Once it is public, the GitHub Advisory Database and OSV pick it up, so a self-hoster running a dependency scanner is told to upgrade.

You do not need to contact a Numbering Authority yourself. We would rather keep the identifier and the fix on one timeline, so the write-up does not point at the flaw before self-hosters can close it. If we judged that a finding did not warrant a CVE, or we could not handle one, we would tell you and leave you free to request it.