Best practice for resthook security - invalid signature

  • 10 March 2021
  • 1 reply

I’m developing a Zapier app, via the CLI, that uses RestHooks.

I want to support signed webhooks, so when the Zapier user, when making a zap, creates the integration with my app, in addition to putting in their api key (for my service), they can optionally add in a shared secret, which will be used to sign the webhooks from my service to Zapier.

I’m checking the signatures in the “perform” function, but I’m not sure what the best practice is, when the verification fails.

Right now, I’m throwing a `z.errors.HaltedError`, but this is not doing what I expected.

When I send a bad signature, when I fetch logs, I see the HaltedError, but the customer’s Zap shows as “Success”, including data about the second step in the Zap.

Zapier is also returning a 200 response to the webhook - which is fine, as we don’t really want the attackers to keep trying.

So, my question is, when an inbound webhook fails the validation (ie, it is being replayed or is otherwise an attack), what error should I throw so that the customer’s properly informed and not charged for zap run/attack/etc.


1 reply

Userlevel 6
Badge +9

Hmm. Seems like that should keep the Zap from proceeding. I know I’d tested that with a polling trigger just the other week. (Sidebar: I actually found it too effective - if the trigger throws halted on its first run, the Zap will unceremoniously turn itself off. TLDR be careful with halted in polling triggers.)


For the sake of debugging, try switching to a general error and see if that changes the behavior.  Also you might add some z.console.log statements around that area of your code and make sure that it’s in fact reaching the error as you expect.  Let us know what you learn. If I get some time later I’ll write a test to explore for myself what goes on with halted in hook performs.  Not sure I’ve ever actually done that, and it is possible it doesn’t behave the way I’d expect.