fix(webhooks): sign outbound webhooks with a dedicated secret, not JWT_SECRET

YousifShkara commented

2026-07-03 11:21:11 +02:00

Owner

Before this change bunyip-api/src/main.rs constructed the WebhookService with jwt_secret.clone(), meaning every RP that verified a bunyip webhook had to hold bunyip's access-token signing key. That is a far too broad grant: the same secret that verifies an account_deleted payload could also mint valid bunyip access tokens for any user. And any rotation of JWT_SECRET (which happens for its own security reasons) silently broke webhook verification on the receiving side in flight, with no obvious connection between the two symptoms.

Split the two secrets. Read a new BUNYIP_WEBHOOK_SIGNING_SECRET via the shared secret_env helper (which resolves BUNYIP_WEBHOOK_SIGNING_SECRET_FILE first for compose secrets, then the plain env var for dev .env). Same fail-shape as JWT_SECRET: production panics if unset, dev/test falls back to a stable placeholder so just dev still boots. Pass the new value to WebhookService::new; the service itself is unchanged (its signing_secret: String field takes whatever the caller passes).

Rollout: the value MUST match what mokosh-server already holds in its own BUNYIP_WEBHOOK_SECRET on the same host, or every subsequent account-delete webhook fails HMAC verification and the mokosh soft-delete never fires. Wiring the secret into the docker compose stacks (c-01 and nc-01 bunyip-api) is a separate change; this PR is code-only. See BUNYIP-332 for the full rollout checklist including the mokosh-server-side comment fix.

Also verified during triage:

WebhookService is used at runtime (constructed at main.rs:378 pre-change / :382 post-change, called from handlers/user.rs::delete_account via fan_out_account_deleted after a real user delete). A prior triage note claiming it was constructed only in tests was mistaken.
Bunyip's Application model has no webhook_secret column; the signing secret is service-wide, not per-RP. mokosh-server's comment describing this as "the same per-app registry row in Bunyip's applications table" is misleading and will be corrected in a matching mokosh-server PR.

#BUNYIP-332

Before this change `bunyip-api/src/main.rs` constructed the `WebhookService` with `jwt_secret.clone()`, meaning every RP that verified a bunyip webhook had to hold bunyip's access-token signing key. That is a far too broad grant: the same secret that verifies an `account_deleted` payload could also mint valid bunyip access tokens for any user. And any rotation of JWT_SECRET (which happens for its own security reasons) silently broke webhook verification on the receiving side in flight, with no obvious connection between the two symptoms. Split the two secrets. Read a new `BUNYIP_WEBHOOK_SIGNING_SECRET` via the shared `secret_env` helper (which resolves `BUNYIP_WEBHOOK_SIGNING_SECRET_FILE` first for compose secrets, then the plain env var for dev .env). Same fail-shape as `JWT_SECRET`: production panics if unset, dev/test falls back to a stable placeholder so `just dev` still boots. Pass the new value to `WebhookService::new`; the service itself is unchanged (its `signing_secret: String` field takes whatever the caller passes). Rollout: the value MUST match what mokosh-server already holds in its own `BUNYIP_WEBHOOK_SECRET` on the same host, or every subsequent account-delete webhook fails HMAC verification and the mokosh soft-delete never fires. Wiring the secret into the docker compose stacks (c-01 and nc-01 bunyip-api) is a separate change; this PR is code-only. See BUNYIP-332 for the full rollout checklist including the mokosh-server-side comment fix. Also verified during triage: - `WebhookService` is used at runtime (constructed at main.rs:378 pre-change / :382 post-change, called from `handlers/user.rs::delete_account` via `fan_out_account_deleted` after a real user delete). A prior triage note claiming it was constructed only in tests was mistaken. - Bunyip's `Application` model has no `webhook_secret` column; the signing secret is service-wide, not per-RP. mokosh-server's comment describing this as "the same per-app registry row in Bunyip's `applications` table" is misleading and will be corrected in a matching mokosh-server PR. #BUNYIP-332

YousifShkara self-assigned this

2026-07-03 11:21:11 +02:00

YousifShkara added 1 commit

2026-07-03 11:21:11 +02:00

fix(webhooks): sign outbound webhooks with a dedicated secret, not JWT_SECRET

Check / fmt + clippy + build + tests (pull_request) Successful in 41m18s

Details

E2E / Playwright against deployment (pull_request) Failing after 6m48s

Details

393a5780ba

Before this change `bunyip-api/src/main.rs` constructed the `WebhookService` with `jwt_secret.clone()`, meaning every RP that verified a bunyip webhook had to hold bunyip's access-token signing key. That is a far too broad grant: the same secret that verifies an `account_deleted` payload could also mint valid bunyip access tokens for any user. And any rotation of JWT_SECRET (which happens for its own security reasons) silently broke webhook verification on the receiving side in flight, with no obvious connection between the two symptoms.

Split the two secrets. Read a new `BUNYIP_WEBHOOK_SIGNING_SECRET` via the shared `secret_env` helper (which resolves `BUNYIP_WEBHOOK_SIGNING_SECRET_FILE` first for compose secrets, then the plain env var for dev .env). Same fail-shape as `JWT_SECRET`: production panics if unset, dev/test falls back to a stable placeholder so `just dev` still boots. Pass the new value to `WebhookService::new`; the service itself is unchanged (its `signing_secret: String` field takes whatever the caller passes).

Rollout: the value MUST match what mokosh-server already holds in its own `BUNYIP_WEBHOOK_SECRET` on the same host, or every subsequent account-delete webhook fails HMAC verification and the mokosh soft-delete never fires. Wiring the secret into the docker compose stacks (c-01 and nc-01 bunyip-api) is a separate change; this PR is code-only. See BUNYIP-332 for the full rollout checklist including the mokosh-server-side comment fix.

Also verified during triage:
- `WebhookService` is used at runtime (constructed at main.rs:378 pre-change / :382 post-change, called from `handlers/user.rs::delete_account` via `fan_out_account_deleted` after a real user delete). A prior triage note claiming it was constructed only in tests was mistaken.
- Bunyip's `Application` model has no `webhook_secret` column; the signing secret is service-wide, not per-RP. mokosh-server's comment describing this as "the same per-app registry row in Bunyip's `applications` table" is misleading and will be corrected in a matching mokosh-server PR.

#BUNYIP-332

YousifShkara referenced this pull request from a commit

2026-07-03 11:46:11 +02:00

test(e2e): stop setInputValue hanging when BUNYIP-331 auto-submit detaches the input

YousifShkara referenced this pull request

2026-07-03 11:48:03 +02:00

test(e2e): stop setInputValue hanging when BUNYIP-331 auto-submit detaches the input #325

YousifShkara force-pushed fix/BUNYIP-332-dedicated-webhook-signing-secret from 393a5780ba

Check / fmt + clippy + build + tests (pull_request) Successful in 41m18s

Details

E2E / Playwright against deployment (pull_request) Failing after 6m48s

Details