Verify webhook origin as Monday.com

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?

Hi @nourishandsow

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?

@nourishandsow

My warmest welcome to the community! That’s a great question.

@basdebruin I appreciate you chipping in on this as well! :slight_smile: 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:

image

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)

@basdebruin

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 :slight_smile: I hope that helps clarify.

-Alex

@AlexSavchuk

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.

@basdebruin

That’s odd - I do see the fields in NGROK when both using in-built triggers:

image

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:

image

Could that work?

-Alex

@AlexSavchuk

oops…my wrong :slight_smile: 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.

1 Like

@nourishandsow

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 :slight_smile:

Thank you and @basdebruin for facilitating healthy discussion here and looking into possible solutions with me!

-Alex