Validate Calls to the MS Flow HTTP Request Trigger

The Highly Versatile and Very Useful HTTP Request Trigger

Our team has found the Microsoft Flow Trigger 'When a HTTP Request is Received' to be an extremely useful addition to our toolbox.

We've used it in cases where:

  • We would like one Flow to call another
  • We would like to return JSON or other data to a script hosted in a page
  • We would like to return markup generated from other systems to be embedded in a page
  • Please, let us know about the cool stuff you've done with this trigger in Flow in the comments below.

In some of the solutions we've created within SharePoint, this Trigger has unlocked new patterns in our CSOM / REST based solutions that weren't possible before. 

 When a HTTP Request is Received {"do" : "awesome stuff"}

When a HTTP Request is Received {"do" : "awesome stuff"}

Heads Up

This awesome trigger is an Azure hosted endpoint that will kick-off an instance of your Flow. This is what makes this trigger so functional and beneficial to us in our solutions.

This also means that this endpoint could potentially be called by anyone with its address.

Here is an example of a URL that is generated by this trigger:

https://prod-67.westus.logic.azure.com:443/workflows/457e21561zr78g86ta018ac10231422de/triggers/manual/paths/invoke?api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=A_z8TpojEj0sQqwT98JNyQA-XoCYEG0beOKvgSpI7WY

The endpoint created by this Trigger is very unique. I've bolded two of the URL parameters above that include long and varied strings of letters and numbers. The complexity of these make it more difficult for someone to find and use your endpoint.

Validating Requests

Below are a few considerations you'll want to take while using this trigger to initiate your Flow.

Planning

Given that it is possible for anyone to access this endpoint, make sure the simple questions have been answered:

  • Is corporate data at risk / exposed?
  • Should this actually be a secure call?
  • What would happen if someone from outside of our organization called this endpoint?

This completely non-technical step is probably the most important one that you'll take. 

Flow Options

Here we will present a couple of simple options you can use with Flow to mitigate the risk of unwanted use of your service.

1 - Create Your Own Secure Token

This quick and easy addition to your Flow requires that callers provide a token when they call your Flow endpoint.

 Check that the caller is providing you with a secure guid / key before continuing your Flow.

Check that the caller is providing you with a secure guid / key before continuing your Flow.

You can validate the requests received by your Flow from calling applications by requiring them to provide you with a key.

Here is a description of our pattern:

  • Trigger: When an HTTP Request is Received
    • Use the relativePath Trigger Property to specify the URL Parameter AccessGuid
    • This changes how callers will use your Flow. The URL for the trigger will now contain the slug /{AccessGuid}/
  • Condition: Evaluate the AccessGuid
    • Compare the value of the AccessGuid Parameter with the value embedded in Flow
  • Action: Control Terminate
    • Stop the Flow if the AccessGuid url does not match the embedded Guid using the Control Terminate Action

2 - Check the Header

You can use the Data Operations - Parse action to parse the Header information received by the When a HTTP Request is Received Action is called.

 Parse the Request's Header information to check the Request's origin information.

Parse the Request's Header information to check the Request's origin information.

In the example above, we use another combination of Conditions and the Control Terminate method to validate that the Request's Header information meets our requirements.

  • Action: Data Operations Parse JSON
    • Parse the Headers value of the Request
      • Open one of the Flow runs and copy the JSON generated in the Headers property.
      • In Edit Mode, add the Parse JSON task, and click the Use sample payload to generate schema link on this Action.
      • All you need to do next is paste in the value you copied in the previous task
    • If you aren't familiar with this Action, this blog post by Serge Luca contains an example of its usage.
  • Condition: Is the Referrer empty
    • We use a formula to evaluate whether or not the referrer is empty: @empty(body('Parse_JSON')?['Referer'])
    • Terminate the Flow if the condition fails
  • Condition: Does the Referrer Match our Domain
    • We use another formula to check and see if the Referrer is our o365 domain (we are planning to call the endpoint from SharePoint Online)
    • indexOf(toLower(body('Parse_JSON')?['Referer']), 'ourprefix.sharepoint.com')

    • Terminate the Flow if the condition fails

Logic Apps

You can step up the options available to you for securing an endpoint if you were to use a Logic Apps Trigger rather than the Flow Trigger we've been discussing in this article - here is a post on this topic from the Logic Apps Team

Although not Flow, it does provide you with other options for automation with a secure HTTP endpoint.

Thank You

Hopefully you find this post helpful.  We'd be interested in hearing about how you're using this endpoint or other methods you have used to validate the requests recevied by this trigger.