Webhooks: Add a way to authorize the webhook request

  • Profile Image
    Asked on August 29, 2016 at 03:47 AM


    is it possible to do a verification of a received webhook to make sure it is sent from JotForms?
    This feature would be very crucial to have a minimum level of security.

    Here is the way Github does it with SHA signing the requests payload with a shared secret.



  • Profile Image
    Answered on August 29, 2016 at 10:02 AM

    I am checking it, and will send you further updates shortly. 

  • Profile Image
    Answered on August 29, 2016 at 10:22 AM

    When the form is submitted, it will post all the form fields data to webhook URL. If you want to pass some other data to webhook, you can add "Hidden Box" widget in your form. You can take advantage of our "URL Parameter" feature to populate the hidden widget with desired values.

    Once the form is submitted, the value of hidden widget will also be posted to webhook URL. You will also get the Form ID, and unique Form Submission id, on Webhook URL. 

    So according to the combination of hidden field value, Form ID and unique Form submissionID, you can verify the form is sent by the Jotform.

    If you want something else, or need further assistance, feel free to revert back.

  • Profile Image
    Answered on August 29, 2016 at 10:31 AM

    Hi  Irshad,

    sorry, but this is no real verification. Everybody is able to see the hidden form field in the browser.
    This means that everybody can fake the call. So this is not secure in any way.

    I'm looking for a more secure and more robust way to do the verification. There are several industry standards on how to deal with verifying server to server requests. (One is the above mentioned way github uses)


  • Profile Image
    Answered on August 29, 2016 at 12:18 PM

    I am note sure if I understood your concern correctly. My knowledge with server to server security using verification might be limited. So apologies if my answer may not suffice. 

    Currently, I am not sure why the need for Webhook verification if you would like to verify that it came from Jotform? Forms, by default, are in HTTPS (SSL enabled) protocol, so the connection between the client and server should already be secured. 

    Here are the information shared to us by our founder about security:

    - We have bug bounty programs where we pay outside parties for

    reporting vulnerabilities in our system.

    - Our servers are protected by private networks and constantly updated

    and patched.

    - Our system administrators have a collective 40+ years of industry experience.

    - Our development team is encouraged to follow best security practices.

    - All data transfer are made of 256-bit SSL secure connection.

    - Our servers are located on SSAE16 Audited facilities.


    Also, the link you shared seems to be related to Github API and the target server of the Webhook. I am not sure if they are the same setup with JotForm. 

    If you want to use a shared token, include it on an HTTP POST on your Webhook URL and send it to your server, want you want to verify that it came from Jotform, then you could try using the full source code instead? Here's a guide about it: https://www.jotform.com/help/104-How-to-get-the-Full-Source-Code-of-your-Form 

    Jotform has an API documentation that you can use here: http://api.jotform.com/. I presume you can setup a somewhat login session to a user when he/she visits your website page, from there you can use your API key as the shared token and attach it to your Webhook URL. Of course you cannot hard code the API key or the shared token in your web page so you'll probably need to have a database and use server side scripting to call it once a session is made. I am not sure if my understanding is correct but I hope that helps.

  • Profile Image
    Answered on August 29, 2016 at 01:24 PM

    Hi Carlie,

    ok, the insecurity lies in the server webhook not beeing able to be verified.
    Here is the szenario.
    We have a server that receives your webhook request.

    You suggested to add a hidden field to the form, lets call it SHAREDSECRETKEY and then use this. to verify the authenticity of the call.
    -> This is bad because an attacker could just look in the forms code (via browser inspector) and figure out hidden field.
    He than can easily reconstruct a post request which looks similar to the one you send and calls our webhook with this.

    So the only way this could kind of work would be with a SHAREDSECRET that is set in the Jotform backend and is just attached in the Webhook. - But it is not used in the FORM!

    The problem with this approach is that then on every webhook request the SHAREDSECRET would be transfered. Not ideal but this could be made more secure by using SSL.

    The best solution (that's the one from github) would be that you use this server side SHAREDSECRET and before sending an webhook request you would use this SHAREDSECRET in combination with a set of transfered fields (i.e. rawRequest) to generate a SHA.

    The receiving end of the webhook would then also use the SHAREDSECRET and the same fileds to also calculate the SHA. If they match then the request is fine.
    If they differ, then the request was tempered with or is fake.

  • Profile Image
    Answered on August 29, 2016 at 03:00 PM

    Unfortunately, we do not support this feature at the moment. I have created a feature request to our developers, we will let you know as soon as there is some update from our developers.

    Thank you for your patience.

  • Profile Image
    Answered on September 01, 2016 at 11:52 AM

    Do you have any info on how likely and when the feature will be implemented?
    This is a pretty serious vulnerability for users of the webhook.

  • Profile Image
    Answered on September 01, 2016 at 01:45 PM

    Unfortunately, it seems like this is will not be implemented anytime soon. But rest assure that we will update you on this thread as soon as we receive any news.

    Thank you.

  • Profile Image
    Answered on November 15, 2016 at 11:00 AM

    Any news on this?
    We are seeing rouge requests coming to our server from different sources once in a while.
    So the verification would really be appreciated.

  • Profile Image
    Answered on November 15, 2016 at 12:20 PM

    I would like to give you a better news, but unfortunately this feature is still not implemented. And it may not be implemented anytime soon based from the status of it in our priority list. 

    I'm not sure if this approach would help, the form is already in SSL, so the connection between server and client should already be secured and can't be tampered (I presume). 

    Instead of adding the Webhook in the Webhook integration, would it be possible to add it directly in the "Thank You" page as the direct landing target? With that, Jotform to landing page should be secured already. This is how I am visualizing it:

    1. User fills out the form

    2. User is redirected to landing page (https://www.company.com/verify.php). 

    3. verify.php will save submission ID in your database, there's a column in the database that says "Verify_Status".

    4. In the same verify.php, it will try to use Jotform's API to check if the submission ID does exist in your Jotform account's list of submission.

    5. If submission ID is found or it returned TRUE by the Jotform's API then update your database specific to that submission ID that was previously saved, update the column "Verify_Status" to "Verified". This verification process is done ONE TIME, so those users who try to make a fake POST call using an existing submission ID should not be possible. 

    6. On the same script, if the verification process is completed then proceed on triggering the main Webhook function. 

    7. Now from your verify.php to another script, you can implement the Github sharedkey if I am not mistaken. 


    So what I am visualizing is an in-between script that should act as the verification process by verifying existing of submission ID as ONE TIME. 

    I'm not sure if this is something that would work for you, but I hope it gives you an idea.