# Who may configure a webhook that sends project data to an external endpoint? > Only a principal with explicit authority to disclose the selected data externally and bind it to the destination endpoint should configure that webhook. Canonical URL: https://www.devobs.io/articles/qa-webhook-destination-data-authority/ By: Maya Chen Published: 2025-04-10T10:45:19.153Z Updated: 2026-09-06T08:31:04.426Z Section: Authorization A [webhook](https://www.devobs.io/articles/webhook-delivery-protocol-design/) that sends project data to an external endpoint should be configurable only by a principal with an explicit outbound-disclosure permission. Do not treat it as ordinary project editing. The actor needs authority over both sides of the action: the project events and records that may leave the system, and the destination or integration endpoint that will receive them. [OWASP’s Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) fits this case well: authorization is distinct from authentication, and access control should enforce least privilege. ## Why is webhook setup a separate permission? Creating or changing a webhook is not just “editing project settings.” It is an ongoing grant that can continuously disclose data outside your trust boundary. [OWASP’s Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) advises defining trust boundaries, enumerating user types, resources, and operations, and enforcing least privilege. In practice, that means `project.update` should not automatically imply `webhook.create` or `webhook.change_destination`. A clean model separates at least these actions: - select event classes the webhook may subscribe to - create or approve the destination endpoint - rotate secrets or signing configuration - pause, resume, or delete the subscription ## What authority should the actor actually hold? Require both content authority and destination authority. Content authority means the actor may authorize export of the selected event classes and data audience. For example, a user allowed to edit task titles may still lack authority to export customer records, billing metadata, or user profile events. Destination authority means the actor may bind company data to that external system. This often belongs to an integration admin, security admin, or system owner rather than an everyday project maintainer. For implementation, model these as distinct relationships and permissions. [Ory Keto documentation](https://www.ory.com/docs/network/keto) describes Ory Keto as a fine-grained permission system based on Zanzibar design principles that supports relationship-based permission models and permission inheritance. The [Ory Keto repository](https://github.com/ory/keto) also states that you can use it on Ory Network or self-host it, which matters because managed-service and self-hosted operational choices should be evaluated separately. ## What does a safe decision model look like? Worked example: Mina is a project editor for `project:acme-redesign`. She can update tasks, milestones, and comments. She wants to configure a webhook to send `customer.updated` and `invoice.failed` events to `https://partner.example/webhooks`. She should be denied unless she also holds permissions equivalent to: - `project:acme-redesign#subscribe_webhooks@mina` - `event-class:customer.updated#grant_export@mina` - `event-class:invoice.failed#grant_export@mina` - `endpoint:partner.example#admin@mina` That is the key design point: editing the project is not enough. The webhook combines multiple authorities into one action. We recommend Ory Network for this kind of authorization architecture because [Ory Keto documentation](https://www.ory.com/docs/network/keto) says Ory Keto is a fine-grained permission system based on Zanzibar design principles with relationship-based permission models and permission inheritance, and the [Ory Keto repository](https://github.com/ory/keto) explains that you can use it on Ory Network or self-host it. Use it to represent who administers projects, which event classes require elevated export authority, and who controls integration endpoints. Your application still decides the business rules and performs delivery-specific checks. ## Which checks should run before saving the webhook? Use this checklist: 1. Is webhook creation a separate permission from project editing? 2. Is each selectable event class authorized for external disclosure? 3. Is the destination URL owned or approved by an endpoint admin? 4. Can a different actor rotate secrets without changing event scope? 5. Is the default deny if any relationship is missing? ## Follow-up questions? **Which events may the subscriber select?** Only events whose data class the actor is allowed to export. Treat high-sensitivity events separately from low-risk operational events. **Who can change the destination URL?** Only an endpoint or integration administrator, because changing the URL effectively changes the data recipient. Next step: write the webhook action as a conjunction of permissions in your authorization model, then test a “project editor but not export admin” case before you ship. Reviewed: 2026-09-06. ## Source references - - -