I want to secure my flows by restrict IP address, tenant, group, users for HTTP - Request trigger.
1. Restrict in my company ipaddress to use my flows which trigger by HTTP - Request.
2. Restrict in my users of our Office 365 group to use my flows which the trigger by HTTP - Request and use from SharePoint - Flow menu.
Current, Anyone who know HTTP POST URL of the trigger, can use our Flows.
At SharePoint, When create Flow by template 'Complete a custom action for the selected item', the new flow by trigger HTTP - Request, and can use anyone who know HTTP POST URL.
Thank you for the idea, we will evaulate this.
Thank you for your vote to this idea - Security - restrict HTTP - Request trigger by IP address, tenant, group, users .
Please comments your think, and your scenarios.
We also have a similar requirement in which we want to enforce security on the HTTP POST URL to restrict access to this url.
Any ideas would be appreciated.
@Stephen Are there any updates here? It is very difficult to build flows, especially those realted to personal data, without the option of restricting who can make calls to our HTTP endpoints.
Adding this feature would massivly increase the types of flows we can create. Today we are restricted due to this security vunerability.
The Security is a mandatory requirement to use the personal data.
Has there been any update on this item? as security is the key to start using this action actively
Almost a year under review?! What's going on here?
@Stephen: When will this continue? Are there any news here?
We really need to have a secure solution for using HTTP requests within Flow...
For an HTTP triggered flow there are a number of ways to restrict this flow. Depending on the flow itself, you will always want to put a check at the very first step of the flow and determine if the criteria was met - if not then you route the flow to the terminate action.
So when the flow comes in there are properties that you can require are passed in the body of the flow. As such you can require a specific GUID is passed in for a specific operation, and then you could also check to ensure that that GUID is an active request if not then you exit.
You could also check the header that is passed in with the call to inspect certain properties like the calling action name among other things.
HTTP flows are very powerful and allow for operations in a larger scope than just your local environment, however, you do need to be aware of they scope that they are in - which is global. So anything that is in the header you can query for - but any call can always be spoofed so you can not 100% just rely on that - you will always want something else that can be passed to that flow to allow for additional validation.
This is an alternative: https://www.about365.nl/2018/11/13/securing-your-http-request-trigger-in-flow/
In this alternative we have to run this trigger from another flow.In that case how would we secure the other flow? Our requirement is to execute it from an ajax call.