The integration asks for a callback URL. Your application has one, and it works locally. The same application also has an administrator login, a diagnostics page and a route used for testing.
Expose only the webhook receiver, or explicitly restrict the application’s public routes. Keep administration on a separately authorized path and validate deliveries with the sender’s verification scheme. Giving a provider one callback URL does not prevent someone else from requesting /admin on the same hostname.
Limit the public surface to the webhook receiver
Start by identifying the smallest service that needs to accept the callback. It might be a dedicated webhook receiver with its own listener, or an application that explicitly rejects every public route outside the intended callback surface.
Do not assume that publishing a hostname automatically restricts traffic to the path you typed into a provider’s form. The path is handled by the receiving application or an explicitly configured and supported proxy rule. A hidden link to /admin does not make that route private.
Fibmesh Publish is available with assisted setup. It associates a public hostname with an approved connector and application target. It does not establish a released path-filtering control or a managed visitor-authentication gate. Plan the receiver so its own exposure and permissions are understood.
An administrator interface can remain on a separately authorized private path, where supported. A public callback does not require the person operating it to administer the server through that same public surface.
Public event path
- Machine senderHTTPS request with the provider’s verification material.
- Webhook receiverValidate the delivery before safely accepting and processing its event.
Private administration path
- Authorized operatorUse a separately permitted private path where supported.
- Administration serviceIndividual application login and management permissions.
Conceptual application boundary. A callback URL does not restrict other paths on its hostname. The receiver or a supported proxy must enforce the public surface. Publish does not imply path filtering; verify that separately for the deployment.
Validate webhook signatures before processing events
HTTPS protects the connection to the endpoint. The receiver still needs to determine whether a delivery is authorized.
Use the webhook provider’s verification scheme. For example, GitHub documents signature validation using a webhook secret and the request payload. Preserve the bytes and relevant headers required by that scheme; parsing and re-serializing a body before verification can change the material being checked.
Store the secret in the intended secret-management mechanism, restrict its access and keep it out of URLs and logs. Verify a delivery before letting it trigger a privileged operation. Test a missing signature and an invalid signature as well as the provider’s valid test delivery.
A browser login prompt generally cannot perform this job for a machine sender. The sender must be able to use the authentication method the receiver expects.
Handle duplicate deliveries, retries and replay checks
Treat delivery and business processing as separate events. Providers have their own timeout, retry and manual-redelivery behavior. Read the rules for the provider you are integrating instead of assuming that every request arrives exactly once.
GitHub’s webhook operating guidance discusses delivery identifiers, redelivery and responding promptly. Your application needs an explicit decision about duplicate deliveries and replay protection under its provider’s scheme.
Where processing continues asynchronously, acknowledge only after the receiver has safely accepted the work into the chosen durable mechanism. Track whether an event is pending, completed or failed. A duplicate request should not accidentally create a second irreversible business action, and a failed first attempt should not disappear merely because its identifier was seen before.
These are application design responsibilities. Putting a public address in front of a handler does not add a queue or define transaction behavior.
Separate incoming webhooks from outgoing API calls
In the Publish design, the sender uses HTTPS to the public gateway. HTTPS terminates there. WireGuard protects the transport from gateway to connector, and the connector makes a separate HTTP or HTTPS connection to the application.
If that final connection crosses the local area network (LAN), use HTTPS with certificate validation where the deployment requires protection. A tunnel ending at the connector does not encrypt a later plaintext LAN connection.
The webhook may cause your application to call the provider’s API. That call is a new outbound connection, separate from the reply to the incoming webhook. Publishing the receiver does not supply a stable outbound source address. Assess that requirement independently if the provider’s API uses an IP allowlist.
Test public routes and unauthorized requests
Before handing over the endpoint, send a valid test delivery and inspect the resulting application action. Then test wrong paths, unsupported methods, oversized input under the agreed limits, and requests without valid authentication.
Check the admin and diagnostics routes from the public side. They should behave according to the explicit exposure policy, not merely lack links from the callback page. Check what error responses and logs reveal, especially when validation fails.
Assign an owner for the callback, its secret and the integration at the provider. For temporary integrations, record when to remove the provider configuration and retire the receiver. A useful webhook endpoint has a narrow job throughout its life: accept authorized events, account for their processing and leave unrelated administration outside that public job.
Review Publish’s hostname and application-access boundaries →
