We are using webhooks pretty extensively for some of our workflows, and as we are using them more we are getting more concerned about potential security holes in our applications. Theoretically, if any actor could guess our webhook endpoints, they could begin submitting data to our services and causing havoc. If we want to build something with security in mind, how can we verify that Monday.com is the source of the input to our endpoints? The only information I’ve found is the egress IP address ranges for Monday.com, but nothing like a verification method, similar to Slack’s X-Slack-Signature or Dropbox’s X-Dropbox-Signature headers. Does a verification method like this exist?
Welcome to the community. There is not much you can do to prevent any other service try to post to your endpoint exposed to the internet. However, the webhook endpoint can’t access your boards because the post to your webhook endpoint does not contain a token to use the monday API. When the webhook post to the action endpoint of your app the post needs to contain the signingsecret in the headers. On its turn the action part of your app (providing you are using a custom action) posts to the action endpoint of your backend and that post contains an encrypted token to use the monday API.
Does that makes sense?
My warmest welcome to the community! That’s a great question.
@basdebruin I appreciate you chipping in on this as well! 
Thanks for your input.
I agree with Bas, and I would also recommend considering using our Apps Framework. If your endpoint receives a request from the monday.apps framework, you will always receive the recipe and integration ID, which can help you verify if the data is really coming from monday.com:
What do you think? Let me know.
-Alex
hi @AlexSavchuk that’s an interesting addition to the answer. Are you sure these fields are also included in the even from a webhook (can’t seem to find them)
I’m afraid webhooks will not provide either the recipe or integration ID - but only the subscription ID. Technically, you could also use that to verify if it’s a monday.com webhook (does the exact same subscription ID exist in your Database?), but you are correct here.
I’d suggested to consider using the apps framework instead as it does provide many of the same triggers as our Webhook integration does I hope that helps clarify.
-Alex
Don’t understand exactly what you mean by “using the apps framework”, is that using the builtin triggers in an integration app? I don’t see how these triggers or actions include the fields you mentioned in the payload. I think it’s me not fully understanding.
We aren’t using the Apps SDK for the integrations, just the basic webhook integration. So my question is if there is a signing secret or other method to verify that the source of the input to our endpoints is Monday. Judging from your and @AlexSavchuk 's responses, it looks like the best we can do is whitelisting Monday’s IP range aside from migrating these to the apps framework.
I thought about this, but there’s no way to retrieve the subscription ID for existing webhooks or webhooks created from the UI as far as I can tell. The Monday UI only shows the automation ID for webhook integrations.
That’s odd - I do see the fields in NGROK when both using in-built triggers:
You will not see those when using webhooks, though, so perhaps that is the issue here?
@nourishandsow you will be able to see the subscription ID for any existing webhook by triggering it, as the subscription ID will be part of the payload:
Could that work?
-Alex
oops…my wrong 
I am using the subscriptionId which I get returned when adding a recipe with a custom trigger as unique identifier. I totally overlooked the integrationId.
1 Like
This creates a sort of chicken/egg problem, where you have to know the subscription ID in order to whitelist it, but you can’t get the subscription ID until the webhook actually runs. This may not be too big of an issue when creating webhooks from the API, but when creating them from the UI there isn’t a way to get the subscription ID.
I think a feature for verifying requests from the main Webhook integration would be very useful.
2 Likes
I see what you mean now! I’ve passed this as a feature request to our product team, and I’ve also changed the topic to be placed in the Feature Request section
Thank you and @basdebruin for facilitating healthy discussion here and looking into possible solutions with me!
-Alex
I’m running into the same issue. I totally agree with @nourishandsow and want to verify the origin of webhooks before I make changes to our database.
I’m missing an authorization header in the current webhook support to use it in combination with our app.
1 Like
Thank you for following up here! It’s a request we do see more frequently lately, and we appreciate the feedback. If you can add your vote to this feature request, that’d help us prioritize this change moving forward 
At this time, this hasn’t been implemented yet.
1 Like
This post has been getting some views recently and I want to get some additional context.
For those of you who are using webhooks instead of a custom integration, why did you choose that approach instead of a custom recipe?
You can use custom actions to work around this, because they come with a signed authorization header. When a custom action runs, it POSTs to a Run URL of your choice, which makes it the same as a webhook.
Overhead in setup required for an app vs an http endpoint
3 Likes
From the perspective of somebody wanting to verify a webhook origin, it could be as “simple” as providing an optional signing secret at the time of creation, from both the UI and API. If it’s present, Monday could add a signature field as a header that a consumer who knows the signing secret could verify.
1 Like
Hi, I use a GET parameter in the webhook URL. This also makes the logic in the server script easier to setup. The script returns when no parameter is supplied.
It’s not perfect, but as it is an SSL connection and the requests are not public, abuse seems very unlikely.
1 Like
Any update on this. I have voted on this topic. I too end up in the same situation to authorize the events reaching to my webhook endpoint.
Thanks
There are many reasons to use webhooks in integration apps and not the default triggers. Just to name two:
- The default monday triggers come with there own trigger sentence, you can’t modify that
- If you want to act on several column changes and do want to filter when posting to the action (subscriptionId) you need to do this with webhooks because you have control over which column changes to forard on to the action and which to ignore.
1 Like
Hello @Venkateshwaran and welcome to the community!
I hope you like it here 
I do not have an update on this but I have added your vote internally to this 
Cheers,
Matias