A common security issue in MAKE scenarios that use Custom Webhook trigger

API & Customization
1

Many people build Make scenarios that use a “custom webhook” trigger. They then configure Knack to trigger the Make scenario by adding a little bit of custom javascript to their app that calls the webhook on some event (e.g., a form submission).

This is a great pattern (I use it myself), however, it’s often done insecurely, making it possible for someone unauthorized to trigger your Make scenario (with potentially serious implications for your private data).

The video below explains this issue in detail & provides a worked example (with code snippets & Make scenario blueprints) for how to fix it.

TLDR;

  • Unless you make a special effort, a Make workflow that starts with a “custom webhook” trigger becomes a publicly accessible URL that anyone can trigger.
  • It’s very easy for someone to discover the URL of your custom webhook if you use it in your Knack javascript area code
  • We can greatly improve security of Make workflows by passing the Knack user token when you call the webhook, and validating that token in your Make scenario before running anything sensitive.

The code and Make blueprints referenced in the video can be found here: public-knack-snippets/your-make-webhook-trigger-is-insecure at main · CallumBoase/public-knack-snippets · GitHub

5 Likes
2

This is great @Callum.Boase. I’ve only just started to use webhooks so I’ll be updating them now.

Craig

1 Like
3

Hey @Callum.Boase - Thank you so much for creating this video! I know how much effort goes into making such detailed content, especially on a niche subject. I really value this type of content because you have a fantastic way of making very technical topics easier to understand. :star_struck:

Keep up the great work! :rocket:

2 Likes
4

Great topic! Security can often be overlooked in no-code.

P.S. I agree with @CarlHolmes that you have a talent for simplifying complex topics for the viewer. Nicely done!

2 Likes
5

Hi @Callum.Boase

Would it be possible to use this method if the user is not logged in?

Craig

6

Ignore my question. I realise this wouldn’t be possible.

7

Hi @Callum.Boase

It looks like make may have changed something recently. They have added this at the top of the HTTP module:

image

Evaluate all states needs to be set to No for this to work.

Which is set in the blueprint for the Knack Starter but it’s not in the video.

I’ve probably missed it but the default is yes when you create the module so I took me a little while to find it.

Craig

8

Hey Craig,
Apologies for the slow reply.
As you noted later, this method wouldn’t work if the user is not logged in.

If the user is not logged in, it would be unecessary to validate that a logged in user triggered the webhook. Presumably, this means that any actions the webhook can do are safe for a member of the public to trigger, removing any need for special authorization checks.

9

Thanks for the clarification. I hadn’t seen that option of “evaluate all states as errors…” when making the video.

1 Like
10

Hi Callum

After some testing we figured out that a user not logged in doesn’t have a user token, which makes sense.

We ended up making it slightly more secure by using a search grid then sending the search criteria in the webhook then searching Knack for that specific record in Make.

We then checked that the recordid returned by Make matched the one that was sent in with the webhook. I know this isn’t perfect but it makes it slightly better as a unknown agent would need 4 bits of data to send into the webhook. And it would need to match the record in the make scenario.

We have set up your knack validation scenario today and it works great.

We will be adding it to all our scenarios triggered in code by a logged in user. This will also help save operations in Make as we can trigger scenarios when specific conditions are met before sending the webhook to Make and wasting operations.

Thank you very much.

Craig

1 Like
11

Nice, yep anything we can do (within reason) like this will improve security.

Another thing I do when I can’t use a user token is use a record rule to set some field value before triggering the Make scenario eg a multi-choice field “Make scenario trigger status” with options “Not ready to trigger, OK to trigger, Has already been triggered”.

Then, early in the Make scenario, I check that the field value indicates that it’s ok for the Make scenario to run (field value must be “OK to trigger”).

Again, not perfect, but takes away some ability for a user try and do something they shouldn’t.

1 Like