[security] decide explicitly: a webhook URL can BE the credential (Slack/Discord-style endpoints), and it is stored plain on two objects

[huangyiirene]

Filed by the domain:services PM seat from the #7902 credential-persistence survey (report: comment 5264546868). Unassigned, no pm:queue. For triage to grade.

This card most likely closes as won't-fix. It is filed anyway, because that should be a decision on the record rather than an omission. The survey found it, and a finding that is silently dropped is indistinguishable from one nobody noticed.

The observation

For a whole class of receivers, the URL is the credential — possession of it is sufficient to post. The spec's own example is exactly that shape:

https://hooks.slack.com/services/T…/B…/XXXX

— packages/spec/src/automation/webhook.zod.ts:91. Stored plain on both delivery-path objects:

object · column	evidence
sys_webhook.url	sys-webhook.object.ts:148
sys_http_delivery.url	(per-attempt copy)

Neither is masked, and sys_webhook declares no enable block at all, so it keeps the full default data API (sys-webhook.object.ts:194) — the same condition #7799 called out for the signing secret and #7986 for the headers.

Why won't-fix is the likely and defensible answer

The URL is the routing key. Unlike a signing secret (#7799, fixed) or a header (#7986), it cannot be moved behind Field.secret() without breaking the thing the row exists to do: an operator has to be able to see, search, sort and edit which endpoint a webhook targets, and the dispatcher has to read it on every attempt. A masked routing key is close to a useless row.

So the realistic options are narrow:

1. Accept and record — the URL stays plain; the exposure is bounded by whoever can read sys_webhook, which is the same set that could already read the endpoint they are administering. Probably correct.
2. Narrow the read surface instead of the field — give sys_webhook an explicit enable.apiMethods rather than inheriting the full default API. That is worth doing regardless ([security] webhook custom headers are still cleartext in two JSON blobs — the sibling of #7799 that PR #7901 did not close #7986 already asks for it), and it addresses this without touching the field.
3. Mask only for shapes known to be credential-bearing — pattern-matching Slack/Discord hook URLs. ⛔ Not recommended: a denylist of URL shapes is exactly the kind of rule that silently fails on the next provider.

What this card actually asks for

One sentence, on the record, choosing between (1) and (2) — and if (1), saying so in a place a future audit will find, so the next credential survey does not re-open it as an unexamined hit. The survey's own standard applies here: a declaration is not load-bearing unless something enforces it, and an omission is not a decision unless someone wrote it down.

Explicitly NOT claimed

• No leak is asserted, and no change is recommended to the field itself.
• Not a regression — predates everything landed today.
• This is not [security] webhook custom headers are still cleartext in two JSON blobs — the sibling of #7799 that PR #7901 did not close #7986. That card is about the headers map, which has a real fix; this one is about the url, which probably does not.

Routing note

Landing site, if anything lands, is plugin-webhooks / platform-objects — but option (2) is already inside #7986's scope, so triage may reasonably decide this card's whole content is "a line in #7986's disposition" rather than independent work. That would be a fine outcome; it is still better than the line never being written.

Evidence

Measured 2026-08-12 by the dev on #7902 (read-only survey, pr: null). Full 26-surface verdict table in comment 5264546868.

Source

Split out of #7902 (survey item ②-b). Siblings: #7986, #7987, #7990, #8009, #8011.

[hotlong]

Triage: lands in domain:services; rationale: the two storing objects are on the services/webhook surface. Held as finding — the card's ask ("decide explicitly whether a webhook URL is treated as a credential") is a storage-posture decision; when the finding-triage round grades it, the likely outcome is escalation to needs-user-decision with the four-prong block, since treating URLs as secrets changes what operators can read back. Not queueing work ahead of that decision. Type: Task.

---

Generated by Claude Code

[hotlong]

Finding-grading round: escalated to needs-user-decision (domain:services), narrowed to one question.

Re-verified: sys_webhook.url is plain Field.text with no enable block, so the full default data API applies (counter-checked against sys-sso-provider, which does declare apiMethods). The API-exposure half (explicit enable.apiMethods) is already inside #7986's dispatched scope — so the only question left here is storage posture: is a webhook URL treated as a credential (encrypted at rest, redacted on read) or accepted-and-recorded as a routing key? Slack/Discord-style endpoints ARE bearer credentials; ordinary endpoints are not, and the platform cannot tell them apart.

Four-prong analysis:

• Platform long-term coherence: treat-as-secret aligns with the [security] The webhook signing secret is stored in cleartext in sys_webhook.definition_json #7799/[security] sys_http_delivery.headers_json still stores webhook credentials in cleartext — and every services-lane shape for fixing it is structurally wrong #8118 family; but unlike headers, the URL must be readable by every list UI and delivery log — full secrecy fights the object's own consumers.
• Measured business pull: no incident; the exposure requires data-API read access to sys_webhook, which [security] webhook custom headers are still cleartext in two JSON blobs — the sibling of #7799 that PR #7901 did not close #7986's apiMethods work is already narrowing.
• AI-agent error-resistance: an explicit ruling recorded on the object definition prevents the next agent from "fixing" it either direction ad hoc.
• Startup scope discipline: accept-and-record costs one docblock sentence; treat-as-secret costs an encryption path + redaction rules + UI changes on a surface [security] webhook custom headers are still cleartext in two JSON blobs — the sibling of #7799 that PR #7901 did not close #7986 is already tightening.

Recommendation: accept-and-record as residual risk (one sentence on the object definition naming Slack-style URLs as the known exposure, deferring encryption until a measured incident or customer requirement), with the read-surface narrowing left to #7986. One sentence from the maintainer settles it.

---

Generated by Claude Code