Product update: Improved Webhook integration security
What’s in this article
We are constantly improving our integrations. This time we focused on the security of our Webhook integration.
Webhooks are powerful because they let Ybug send data to your own systems in real time. A new feedback report can trigger an internal workflow, create a ticket, update a dashboard, notify a service, or start an automation. But because webhook endpoints are usually publicly accessible URLs, it is important to verify that incoming requests are really coming from Ybug.
Why webhook security matters
Webhooks deliver data to publicly accessible URLs. They are often secured just by obscuring the endpoint URL, where every user obtains a unique URL to send webhook data to. Anyone with knowledge of the endpoint URL can send data to it.
That is usually not enough for production workflows. If your webhook endpoint creates tickets, stores customer feedback, triggers deployments, or updates internal systems, you need a way to check that the payload was sent by Ybug and was not forged by somebody else.
New optional webhook signature
We have added an optional extra security layer to our webhooks. You can now specify a secret token which will be used by Ybug to compute a signature of the payload sent to your webhook endpoint. Every webhook request then contains the X-Ybug-Signature header with this signature. This way, you can verify that the webhook request really originated from Ybug.
How signature verification works
The idea is straightforward:
- You configure a secret value in your Ybug Webhook integration settings.
- Ybug uses that secret to calculate a signature for the webhook payload.
- Ybug sends the signature in the X-Ybug-Signature request header.
- Your endpoint calculates the expected signature using the same secret and the raw request body.
- Your endpoint compares both signatures before processing the webhook.
If the signatures match, the request is very likely to be authentic. If they do not match, your application should reject the request and avoid processing the payload.
Practical implementation tips
- Use a long random secret. Avoid readable passwords or reused API keys.
- Store the secret securely. Put it in an environment variable or secret manager, not directly in source code.
- Verify the raw request body. Do not verify a re-encoded JSON object because formatting changes can alter the signature.
- Use a constant-time comparison. This helps avoid timing-based signature comparison issues.
- Reject failed verification early. Return an error before creating tickets, sending notifications, or storing data.
- Rotate secrets when needed. If a URL or secret may have been exposed, generate a new secret and update your endpoint.
Example: secure feedback ingestion
Imagine you use Ybug webhooks to create issues in an internal system. Without signature verification, anyone who discovers the endpoint URL could send fake feedback data. With the secret and X-Ybug-Signature header enabled, your endpoint can verify the request before creating anything.
This protects your internal workflow from noise and keeps your webhook endpoint safer even though it is reachable from the internet.
When should you enable webhook signatures?
We recommend enabling signatures whenever your webhook endpoint does more than log a simple notification. It is especially important if the webhook:
- creates or updates records in your database,
- opens tickets in a project management tool,
- triggers alerts, emails, or automation,
- stores user-submitted content,
- connects to internal systems.
Please read our documentation to learn more about configuring and verifying webhook signatures.
