Secure Input and Output in Azure Logic Apps
When you work with Azure Logic Apps, anyone with access to the run history can, by default, see all the data transferred and received by the app’s actions and connectors. This can be a security concern, especially when handling sensitive information like medical data or authentication credentials. In such cases, it is crucial to secure this data from unauthorized viewing.
In this blog post, we will explore strategies for overcoming challenges associated with Secure Input/Output in Azure Logic Apps, particularly in non-production environments. While Secure Input/Output is a crucial feature for protecting sensitive data in production, it can introduce hurdles during development and testing phases where visibility into data flows is essential for effective debugging.
Why Use Secure Input/Output?
Azure Logic Apps provides a feature called Secure Input/Output. This feature allows users with access to the run history to see that actions occurred without revealing the sensitive input and output data.
- Protect Sensitive Data: Ensure that confidential information such as personal health information (PHI) or login credentials is not exposed to users who might access the logic app’s run history.
- Compliance: Meet compliance standards such as GDPR or HIPAA by ensuring sensitive data is not unnecessarily exposed.
- Data Integrity: Maintain the integrity of your data by preventing unauthorized access and potential data leaks.
How to Enable Secure Input/Output
Enabling Secure Input/Output in Azure Logic Apps is a straightforward process. Follow these steps to configure it:
Challenges in Non-Production Environments
While securing data in production is crucial, it can create challenges in non-production environments where debugging and testing require visibility into data flows. Here are some common issues:
- Troubleshooting Difficulty: Secure input/output settings can hide necessary data, complicating troubleshooting efforts in non-prod environments.
- Reduced Risk: Non-production environments typically use scrambled or non-sensitive data, posing less risk if exposed.
A side effect of configuring Secure Input/Output is that every subsequent action referring to the initial secured action will also hide its data. This makes troubleshooting even more challenging.
For instance, see the example below where only the “Send Secure HTTP Request” action has Secure Input enabled:

I have submitted an idea to Microsoft to address this issue in non-prod. You can find the link to this idea here. Please consider voting if you find this helpful.
Solution approach
To address these challenges, I developed a solution with the following goals:
- Maintain Secure Input/Output in Production: Keep security features active in production while disabling them in non-production environments.
- Minimize Impact on Development Teams: Implement a solution that is easy to integrate with existing CI/CD processes.
- Ensure Production Safety: Ensure that any failure in the automation process does not block production releases.
Logic App Secure Input/Output Remover
The Logic App Secure Input/Output Remover is a tool designed to run in a DevOps pipeline, automatically removing configured secure input/output settings from actions in a Logic App Standard. The source code is available on GitHub.
Here’s how it works:
- Deployment Process: Your Logic App Standard solution is compiled and deployed as usual. In non-production environments, an additional step modifies the workflow.json files to remove secure input/output settings.
- PowerShell Script: The script, written in PowerShell, integrates directly with the active Azure context connection.
Below is an illustration of the design:

Secure Input/Output Under the Hood
Below is a sample action with SecureData configuration enabled. The highlighted lines will be removed by the PowerShell script:
"Send_Secure_Http_request": {
"inputs": {
"headers": {
"Authentication": "Basic mfgmhfdsmhfsdmhudfsmhujkfds"
},
"method": "POST",
"uri": "https://yourwebsite.com"
},
"runtimeConfiguration": {
"contentTransfer": {
"transferMode": "Chunked"
},
"secureData": {
"properties": [
"inputs",
"outputs"
]
}
},
"type": "Http"
}Technical Explanation
Initially, I expected to use a few simple PowerShell commands to modify the workflow.json files in a Logic App Standard. However, no Azure PowerShell cmdlets exist for this purpose. Instead of using outdated FTP methods, we leverage the Kudu API to modify the underlying directory and files.

Alternative Solutions
An alternative approach could involve creating different deployment packages for each environment, modifying them accordingly. This method can speed up the release process by reducing the need to interact with Kudu and allowing pre-release build actions.
Ideally, this functionality should be built into Azure Logic Apps, with control at the app level rather than the action level. If you agree, please support my suggestion to Microsoft by voting on the idea here.
