Try for free Book a demo

Improving Logic App security by suppressing workflow headers in external HTTP calls

Microsoft Azure

4 Mins Read

Logic App security in external HTTP calls featured image

Welcome again to another Logic Apps Best Practices, Tips, and Tricks. In my previous blog posts, I discussed some essential best practices and tips and tricks you should have while working with the Azure Logic Apps.

Today, I will speak about another helpful Logic App best practice that you must consider while designing your business processes (Logic Apps), in this specific case, in the security of our components and Azure platform: Improve Logic App security by suppressing workflow headers in external HTTP calls.

Logic App security in external HTTP calls

Improve Logic App security by suppressing workflow headers in external HTTP calls

You may have never noticed, but you are most likely unintentionally sharing sensitive information about your Azure platform with third parties, and all because the HTTP connector, by default inside Logic App (or even Power Automate), is sending in the headers of the payload several pieces of information about the workflow that is making the call. This is also something that security departments are not aware of. But to explain better, let’s make a small proof-of-concept.

To prove/demonstrate this behaviour, let’s create two simple Logic Apps:

  • A main Logic App triggered by an empty HTTP > to be easier to start and test.
  • And a child Logic App that will act like a third-party system service.

Creating the child Logic App

Let’s start by creating the child Logic App:

  • Create an empty Logic App from the Azure Portal (or the editor of your choice)
  • Add a Request > When a HTTP request is received trigger to our blank Logic App.
  • Now, add a Request > Response action and configure the response as:
    • On the Status Code property, set it to 200.

Add a Request data-srcset= Response action and configure” />

  • Save it and copy the HTTP URL because we are going to need it for the primary process.

Now, let’s create our primary process:

  • Create an empty Logic App from the Azure Portal (or the editor of your choice)
  • Add a Request > When a HTTP request is received trigger to our blank Logic App.
  • After the When a HTTP request is received trigger, select Add an Action.
  • On the Choose an operation panel, search for HTTP and then choose the HTTP action.

Choose an operation panel, search for HTTP

  • On the HTTP action, set the following configurations:
    • Method: Set as POST.
    • URI: Copy the HTTP POST URL child Logic App into here.
    • Body: Add a dummy body if you prefer, something like:
{
"Test": "Test"
}
  • Now, add a Request > Response action and configure the response as:
    • On the Status Code property, set it to 200.

Add a dummy body in the HTTP action

  • Save it.

Now that we have created our two Logic Apps, let’s test them and prove this vulnerability by:

  • Executing the primary Logic App.
  • Once it finishes, let’s go to the child Logic App run history and select the execution

Go to the child Logic App run history and select the execution

  • On the Logic App run, expand the When a HTTP request is received and click on Show raw outputs.

Clicking on Show raw outputs

  • This will present all the headers and body that are being passed to this Logic App (or service if it was an external web service). There you see that, by default, the following sensitive information is being passed:
    • Your subscription id: x-ms-workflow-subscription-id
    • Your resource group name: x-ms-workflow-resourcegroup-name
    • Name of your Logic App: x-ms-workflow-name
    • Location: x-ms-execution-location
    • Workflow run id: x-ms-workflow-run-id
    • IP address: CLIENT-IP

Logic App security in external HTTP calls

All of this information shouldn’t be passed to services outside your organization, and even in most cases, it should also be passed to internal services. These can be considered vulnerabilities because you are sharing information that can help others to exploit vulnerabilities in your system.

Unfortunately, this is the default behaviour of the HTTP connector, which in my opinion, is wrong. It should be the opposite! The good news is that we can control this behaviour easily! To accomplish that, we need to:

  • Access the HTTP action inside the primary process, click on the three dots (…), and then click Settings.

Accessing the HTTP action inside the primary process

  • On the Settings for ‘HTTP’ panel, scroll down and enable the Suppress workflow headers option. Then click Done.

Enabling the Suppress workflow headers option

  • And finally, Save these changes.

Now if we do the same test we did previously, we will see that in the child run history, all those headers are not present now:

Logic App security in external HTTP calls

I hope you enjoy this developer tip and stay tuned for the following Logic App Best practices, Tips, and Tricks.

Related reading

This article was published on Dec 6, 2023.

Related Articles