Hook0 service tokens need attenuation before they leave the backend

Hook0 is a webhook delivery service that can be self-hosted or used as a managed service. Its API creates applications, subscriptions, event types, and delivery records. Service tokens authenticate automated API calls on behalf of an organization.

The service-token model is more capable than a simple application API key. Hook0 documents service tokens as organisation-scoped by default, with Biscuit-based offline attenuation. A team can restrict a token to specific applications, an expiry, or read-only operations without contacting Hook0. Revoking a root token invalidates its derived tokens.

What ZoomEye observed

The 2026-11-12 count-only probe used sub_type=all, page 1, and page size 1. app="Hook0" returned 0. title="Hook0" returned 10. http.body="Hook0" returned 63.

Search dork: title="Hook0".

Search link: ZoomEye Hook0 title query.

Body query: http.body="Hook0".

Search link: ZoomEye Hook0 body query.

The small title set may include documentation and unrelated pages. Validate the product response before treating any asset as a Hook0 deployment. The app zero value is not proof that no self-hosted instance exists.

Separate service and application tokens

Hook0 uses service tokens for organisation-level API access and application secrets for application-specific event ingestion. The service token can manage applications, subscriptions, and service credentials. The application token sends events and is scoped to an application.

Use the narrowest token for each workflow. A backend that sends events should not hold an organisation-wide management token. If the product supports attenuation, create a derived token limited to the application and operation set. Keep the root token offline or in a protected secret manager.

Review self-hosted master API keys separately. Hook0 documents a master API key for self-hosted instances. It should not be distributed to tenants or embedded in client software.

HMAC and delivery records

Hook0 signs webhook deliveries with HMAC-SHA256 using a subscription secret. The receiver must verify the signature over the raw request body and check the timestamp or replay policy where applicable. A valid signature proves possession of the secret, not that the event business logic is safe.

Delivery logs and replay endpoints are administrative data. They can reveal payloads, endpoint URLs, errors, and retry behavior. Restrict who can inspect them and redact sensitive fields from payloads before they reach the webhook platform.

Review the self-hosted surface

List the API base URL, dashboard, docs endpoint, and health endpoint. Confirm which are reachable from the internet. Keep the API behind authentication and rate limits. Review database and object-store credentials used by the service, then test a token attenuation rule and a revoked token.

Monitor for repeated authentication failures and for service tokens used outside their expected source network. A token is a bearer credential; possession is enough unless another control constrains its use.

References