Laravel Config Webhook Laravel Package

Product Decisions This Supports

• Security review / procurement unblock. The 1.1.0 SSRF hardening (refusing private, loopback, link-local/cloud-metadata and reserved targets at both save and send time, no redirect following, DNS pinned to the checked IP) is the control auditors and enterprise buyers ask for when a product makes arbitrary outbound HTTP requests. This is the difference between "we roll our own webhooks" and "we pass the questionnaire."
• Go/no-go on shipping user-supplied webhook URLs. If your roadmap includes letting customers or tenants configure their own endpoint (integrations, automations, event subscriptions), this release is the gate that makes that feature defensible. Before it, an attacker-controlled URL was a pivot into your VPC and cloud metadata.
• Support-cost and reliability decision. Sending the exact signed JSON string (rather than a re-encoded body) fixes the class of "receiver says signature invalid" failures that are painful to triage and frequently blamed on your product. Budget a reduction in integration support tickets and partner escalations.
• Breaking-change rollout planning. The behaviour change is real: existing webhooks pointed at internal addresses stop delivering and are marked failed with no retry. That drives a decision — do you ship a migration/audit pass (enumerate stored endpoints, flag internal targets, notify owning tenants), gate the upgrade behind a release note, or hold the upgrade until the audit tooling exists?
• Environment parity decision. The new allow_private_hosts flag (CONFIG_WEBHOOK_ALLOW_PRIVATE_HOSTS, default false) is the right shape for local/staging development, but it is a production footgun if it lands in shared config. Decide now whether prod config is locked and who can flip it.
• Build vs buy. The package is thin, but the last release is exactly the work an in-house implementation defers indefinitely. Continuing to depend on it is cheaper than owning SSRF defence, DNS pinning and signature-fidelity guarantees yourself.
• Versioning/communications decision for engineering. A breaking behaviour change shipped in a minor (1.1.0) means the semver contract cannot be relied on for upgrade safety — worth deciding whether you pin versions and review changelogs manually.

When to Consider This Package

• You need outbound webhook delivery in a Laravel app and are willing to accept a small, opinionated dependency rather than building delivery, signing and retry logic in-house.
• You are exposing webhook configuration to end users or tenants, and outbound URLs are therefore attacker-influenced. The 1.1.0 controls are the reason to adopt rather than the reason to hesitate.
• You are on 1.0.1 and have internal-target webhooks (staging hooks, internal service callbacks, private-network integrations). Treat 1.1.0 as a breaking upgrade: audit stored URLs first, enable allow_private_hosts only in non-production, and expect affected endpoints to fail without retry.
• Look elsewhere if you need guaranteed semver stability for automated upgrades, first-class queue/backoff/bulk-redelivery tooling, a management UI, or delivery observability beyond failed status — this package is a delivery primitive, not a webhook platform.
• Look elsewhere if your architecture legitimately requires delivery to private networks (on-prem agents, customer VPC endpoints). The new default refuses those; you would be running with a permissive flag permanently on, which forfeits the security benefit.

How to Pitch It (Stakeholders)

To executives: This release closes the security hole that made "let customers configure their own webhooks" a risky bet — our app can no longer be tricked into calling internal systems or cloud metadata endpoints, and signed payloads now verify correctly on the receiver side, which removes a recurring source of partner escalations. It is a low-cost dependency upgrade that materially strengthens our security posture and shortens enterprise security reviews.

To engineering: Upgrade to 1.1.0 deliberately, not automatically. It is a minor version carrying a breaking behaviour change: any stored webhook pointing at private, loopback, link-local or reserved addresses stops delivering and is marked failed with no retry. Before rolling out, enumerate existing endpoints, confirm which are internal, notify affected owners, and restrict allow_private_hosts to local/staging config only — never enable it in production. The signature fix means receivers must verify against the raw request body; confirm our own receivers do so.