The “When an HTTP request is received” trigger is one of my favourite building blocks for creating serverless processes with low-code workflows technologies like Power Automate or Azure Logic Apps (you can conquer the world with this trigger :D).
Two years ago I wrote a post about some basic tricks for securing an HTTP-triggered Power Automate workflow. The post can be found here and I think you should apply some of the described tips in your Power Automate workflows if you want to avoid that everyone with the workflow url being able to trigger your flows.
Today I received a request from a customer where security is on top of the IT department’s attention. They started using Power Automate for some HTTP triggered-workflows following the suggestion of my previous post, but when analyzing the responses sent back by Power Automate to the caller, they have discovered something that they consider not so good and secure.
Before start explaining the topic, I have to say that my personal rule on this topic is: when a cloud workflow need to start with the “When an HTTP request is received” trigger and the trigger is an external application, this workflow is a good candidate for Azure Logic Apps if you want to be secure and scalable. Think about this please…
Closing this brackets, what’s the raised problem here?
To explain that, let’s consider a simple Power Automate workflow that receives an HTTP request, does some actions and then returns a response if the action is completed successfully. The workflow can be defined as follows:
Here the workflow receives an HTTP request with a JSON message from an external application containing the following body:
{
"messageSubject":"",
"messageBody":"",
"email":""
}
Then the workflow performs some actions you want (like composing an email message with the details in input) and here I simply assing a value to a variable (MessageProcessed set to true). Then, if the MessageProcessed variable is true, the workflow completes successfully (HTTP response 200) otherwise it throws an error (HTTP response 400). Very easy…
Now let’s trigger the workflow by sending an HTTP request to the workflow url (I’m using Powershell for that here). When triggered, the workflow is successfully executed:
If you inspect the workflow response, you can see that it contains a set of headers:
and if we explode the headers, this is the content:
In this set of headers you can see the workflow id and other internal details, not a best practice in terms of security.
Questions raised by the above IT department was: can I avoid to expose these details?
The answer is YES and I forgot to mention that in my previous post.
I think this in not a well-known feature for most of the Power Automate users but on the “When an HTTP request is received” trigger you can click on Settings and then set the Suppress workflow headers option to On. This option permits you to not include workflow metadata headers in the Http response of the flow:
if I now trigger again the workflow, this is the Http response I have:
No metadata headers are exposed now. Much better 🙂
I suggest to turn this feature on if you’re using Http-triggered Power Automate workflows (and always remember that Logic Apps is better for security).
Stefano Demiliani 