# A common security issue in MAKE scenarios that use Custom Webhook trigger **URL:** \ **Category:** API & Custom Code\ **Created:** [June 27, 2024, 4:13am UTC](https://forums.knack.com/t/a-common-security-issue-in-make-scenarios-that-use-custom-webhook-trigger/17475 "2024-06-27T04:13:10Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Callum.Boase](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/callum.boase/32/5729_2.png) [@Callum.Boase](https://forums.knack.com/u/Callum.Boase)\ **Post date:** [June 27, 2024, 4:13am UTC](https://forums.knack.com/t/a-common-security-issue-in-make-scenarios-that-use-custom-webhook-trigger/17475/1 "2024-06-27T04:13:10Z")
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. [![](https://us1.discourse-cdn.com/flex020/uploads/knack/original/2X/2/25d4f0a3e6fa0eaf650383d84c4af4e5c5db6d62.jpeg "Your MAKE webhook trigger is insecure | Knack integration") ](https://www.youtube.com/watch?v=qhiK-eosoco) 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](https://github.com/CallumBoase/public-knack-snippets/tree/main/your-make-webhook-trigger-is-insecure) ---
**Author:** ![CSWinnall](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/cswinnall/32/3631_2.png) [@CSWinnall](https://forums.knack.com/u/CSWinnall)\ **Post date:** [June 27, 2024, 5:48am UTC](https://forums.knack.com/t/a-common-security-issue-in-make-scenarios-that-use-custom-webhook-trigger/17475/2 "2024-06-27T05:48:22Z")
This is great @Callum.Boase. I’ve only just started to use webhooks so I’ll be updating them now. Craig ---
**Author:** ![CarlHolmes](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/carlholmes/32/2814_2.png) [@CarlHolmes](https://forums.knack.com/u/CarlHolmes)\ **Post date:** [June 27, 2024, 6:38am UTC](https://forums.knack.com/t/a-common-security-issue-in-make-scenarios-that-use-custom-webhook-trigger/17475/3 "2024-06-27T06:38:28Z")
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. 🤩 Keep up the great work! 🚀 ---
**Author:** ![KnackPros](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/knackpros/32/807_2.png) [@KnackPros](https://forums.knack.com/u/KnackPros)\ **Post date:** [June 27, 2024, 7:06pm UTC](https://forums.knack.com/t/a-common-security-issue-in-make-scenarios-that-use-custom-webhook-trigger/17475/4 "2024-06-27T19:06:38Z")
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! ---
**Author:** ![CSWinnall](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/cswinnall/32/3631_2.png) [@CSWinnall](https://forums.knack.com/u/CSWinnall)\ **Post date:** [August 6, 2024, 2:09pm UTC](https://forums.knack.com/t/a-common-security-issue-in-make-scenarios-that-use-custom-webhook-trigger/17475/5 "2024-08-06T14:09:22Z")
Hi @Callum.Boase Would it be possible to use this method if the user is not logged in? Craig ---
**Author:** ![CSWinnall](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/cswinnall/32/3631_2.png) [@CSWinnall](https://forums.knack.com/u/CSWinnall)\ **Post date:** [August 6, 2024, 9:12pm UTC](https://forums.knack.com/t/a-common-security-issue-in-make-scenarios-that-use-custom-webhook-trigger/17475/6 "2024-08-06T21:12:54Z")
Ignore my question. I realise this wouldn’t be possible. ---
**Author:** ![CSWinnall](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/cswinnall/32/3631_2.png) [@CSWinnall](https://forums.knack.com/u/CSWinnall)\ **Post date:** [August 13, 2024, 8:38am UTC](https://forums.knack.com/t/a-common-security-issue-in-make-scenarios-that-use-custom-webhook-trigger/17475/7 "2024-08-13T08:38:14Z")
Hi @Callum.Boase It looks like make may have changed something recently. They have added this at the top of the HTTP module: ![image](https://us1.discourse-cdn.com/flex020/uploads/knack/original/2X/4/4fb86887f1265154ddbaf0d1e46f7389eb410508.png) 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 ---
**Author:** ![Callum.Boase](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/callum.boase/32/5729_2.png) [@Callum.Boase](https://forums.knack.com/u/Callum.Boase)\ **Post date:** [August 13, 2024, 8:21pm UTC](https://forums.knack.com/t/a-common-security-issue-in-make-scenarios-that-use-custom-webhook-trigger/17475/8 "2024-08-13T20:21:57Z")
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. ---
**Author:** ![Callum.Boase](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/callum.boase/32/5729_2.png) [@Callum.Boase](https://forums.knack.com/u/Callum.Boase)\ **Post date:** [August 13, 2024, 8:22pm UTC](https://forums.knack.com/t/a-common-security-issue-in-make-scenarios-that-use-custom-webhook-trigger/17475/9 "2024-08-13T20:22:48Z")
Thanks for the clarification. I hadn’t seen that option of “evaluate all states as errors…” when making the video. ---
**Author:** ![CSWinnall](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/cswinnall/32/3631_2.png) [@CSWinnall](https://forums.knack.com/u/CSWinnall)\ **Post date:** [August 13, 2024, 8:35pm UTC](https://forums.knack.com/t/a-common-security-issue-in-make-scenarios-that-use-custom-webhook-trigger/17475/10 "2024-08-13T20:35:22Z")
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 ---
**Author:** ![Callum.Boase](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/callum.boase/32/5729_2.png) [@Callum.Boase](https://forums.knack.com/u/Callum.Boase)\ **Post date:** [August 14, 2024, 11:57pm UTC](https://forums.knack.com/t/a-common-security-issue-in-make-scenarios-that-use-custom-webhook-trigger/17475/11 "2024-08-14T23:57:40Z")
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.