cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
ID3
New Member

Hot to restrict access for HTTP Request Trigger

Dear Experts,
I have simple flow based on "When a HTTP request is received" trigger.

ID3_0-1618785813479.png

Using the link from the trigger, anyone can sent HTTP request and get response from my Flow. And this is really the problem.

How I can restrict possibility to get response from my flow for anyone except certain users?

(Note: I don't want to use some kind of Passwords which I can provide because I can't control that someone of my approved users will not share this password with someone else, and I will not be able determine who exactly use this password - the user approved by me or not.)


Sincerely ID3 



16 REPLIES 16
Expiscornovus
Most Valuable Professional
Most Valuable Professional

Hi @ID3,

 

I don't know if this will work for you situation, but you might be able to check the user-agent value of the POST request and add a trigger condition to your When a HTTP request is received trigger action.

 

Below is an example of a trigger condition which only allows requests from other Power Automate flows and for instance not Windows PowerShell.

 

@startswith(triggeroutputs()['headers']['user-agent'], 'azure-logic-apps/1.0')

 triggercondition_azurelogicapps_useragent.png



Happy to help out! 🙂

Interested in more #PowerAutomate #SharePointOnline or #MicrosoftCopilotStudio content?
Visit my blog, Subscribe to my YouTube channel or Follow me on Twitter


Dear Expiscornovus,

In my case all permitted to access to my Flow users are members of Office 365 groups.
Maybe it is useful information for the solution finding.

One more fact - it is quite enough to restrict the access only for HTTP request been sent from Power Query (Excel). And perhaps in this case the Power Query "Access Web content" options can be used.

ID3_0-1618822413222.png

I actually wrote an article on how to secure the HTTP trigger, check it out and see if it of use to you:

Secure the HTTP Request Trigger in Microsoft Power Automate 

Expiscornovus
Most Valuable Professional
Most Valuable Professional

Hi @ID3,

 

It is still a workaround based on the user agent string, but you can probably use this trigger condition to restrict only to Power Query (web.contents source)

@startswith(triggeroutputs()['headers']['user-agent'], 'Microsoft.Data.Mashup')

 

@Paulie78, nice, very useful article 🙂

However, I think ID3 wanted to avoid using a key or a password like stated in the opening post.



Happy to help out! 🙂

Interested in more #PowerAutomate #SharePointOnline or #MicrosoftCopilotStudio content?
Visit my blog, Subscribe to my YouTube channel or Follow me on Twitter


@Expiscornovus - That will teach me not to read the question properly! Thank you for putting me straight!

ID3
New Member

Dear @Paulie78 
The article about HTTP Request Secure is realy nice. It means I am not alone who met the same problem and it is worth to work it out more.

Dear @Expiscornovus 
Your suggested Microsoft.Data.Mashup check is a good, and I think should be used in any case. 
In case of PowerQuery using with Windows or Organizational account credentials, does it mean that the data about user account (login/user name) can be taken from the trigger/Request? 

Is there any MS Services can provide information about all MS Flow transactions with more details than I can see in Power Automate Runs History?

Sincerely ID3

Expiscornovus
Most Valuable Professional
Most Valuable Professional

Hi @ID3,

 

As far as I could tell it wasn't showing any data about the account which was used.

 

Below is an example of the raw input of the received HTTP request when I was testing it with Power Query in Excel.

 

{
    "headers": {
        "Accept": "*/*",
        "Accept-Encoding": "gzip,deflate",
        "Expect": "100-continue",
        "Host": "prod-21.uksouth.logic.azure.com",
        "User-Agent": "Microsoft.Data.Mashup,(https://go.microsoft.com/fwlink/?LinkID=304225)",
        "Content-Length": "2",
        "Content-Type": "application/json"
    },
    "body": {}
}

 



Happy to help out! 🙂

Interested in more #PowerAutomate #SharePointOnline or #MicrosoftCopilotStudio content?
Visit my blog, Subscribe to my YouTube channel or Follow me on Twitter


Dear @Expiscornovus
Here is what I have and waht I used.
Receiver:

ID3_0-1619256787006.png
And here is the data.

{
    "variables": [
        {
            "name": "Trigger",
            "type": "String",
            "value": "{\"name\":\"manual\",\"inputs\":{\"method\":\"POST\"},\"outputs\":{\"headers\":{\"Connection\":\"Keep-Alive\",\"Accept\":\"application/json\",\"Accept-Encoding\":\"gzip,deflate\",\"Expect\":\"100-continue\",\"Host\":\"prod-96.westeurope.logic.azure.com\",\"User-Agent\":\"Microsoft.Data.Mashup,(https://go.microsoft.com/fwlink/?LinkID=3xxx5)\",\"Content-Length\":\"39\",\"Content-Type\":\"application/json\"},\"body\":{\"Type\":\"MyData\",\"Param\":\"MyData\"}},\"startTime\":\"2021-04-24T09:25:56.997722Z\",\"endTime\":\"2021-04-24T09:25:56.997722Z\",\"trackingId\":\"4xxxxxxb-5xxx-4xxe-xxxxxxxx1\",\"clientTrackingId\":\"0XXXXXXXXXXXXXXXXXXXXXXXXXX4\",\"originHistoryName\":\"0XXXXXXXXXXXXXXXXXXXXXXX\",\"status\":\"Succeeded\"}{\"Type\":\"MyData\",\"Param\":\"MyData\"}"
        }
    ]
}

For sending I used this one request

let
    urlApi="https://prod-96.westeurope.logic.......",
    Request = Json.Document(Web.Contents(urlApi, [ Headers=[#"Accept"="application/json", #"content-type" = "application/json"], Content=Text.ToBinary("{""Type"": ""SiteInfo"", ""Param"": """& Site_Param &"""}")])),
    #"Converted to Table" = Record.ToTable(Request),
    #"Renamed Columns" = Table.RenameColumns(#"Converted to Table",{{"Name", "Parameter"}}),
    #"Changed Type" = Table.TransformColumnTypes(#"Renamed Columns",{{"Value", type text}, {"Parameter", type text}})

in
#"Changed Type"

With this permissions:

ID3_1-1619257180163.png

It is pretty interesting why you have not "originHistoryName" and "clientTrackingId" but I have. Did you use POST or GET?
But however, I don't know are these values can help with my problem or not. ...



The problem is still not solved and important.

Sincerely ID3.

Hi Expiscornovus,

 I've got a question for you, is there any way to send back an error such as 400 Bad Request or 401 Forbidden if the request doesn't satisfay the conditional trigger?

A the moment if I call the https endpoint I receive a standar "202 Accepted" code...

 

Thank you,

Stefano.

Expiscornovus
Most Valuable Professional
Most Valuable Professional

Hi @ZaffaSte,

 

You can remove that trigger condition and use a condition action instead. Use that startswith expression in there and use a response action to send back a HTTP 400.

https://docs.microsoft.com/en-us/azure/connectors/connectors-native-reqres#add-a-response-action

 

Below is an example of that.

 

400response.png



Happy to help out! 🙂

Interested in more #PowerAutomate #SharePointOnline or #MicrosoftCopilotStudio content?
Visit my blog, Subscribe to my YouTube channel or Follow me on Twitter


ZaffaSte
Regular Visitor

Hi @Expiscornovus ,

 thank you for your reply: easy peasy lemon squeezy and it's true, but in this way the flow start, there's no way to default 202 reply other than start a flow?

 

Thank you so much,

Stefano

Expiscornovus
Most Valuable Professional
Most Valuable Professional

Hi @ZaffaSte,

 

I know there is a schema validation setting which you can enable in the settings which can return a HTTP 400 instead of a 200 if there is a mismatch.

 

But as far as I am aware that is only for the body, not the headers like user-agent.

 

schemavalidation_400.png



Happy to help out! 🙂

Interested in more #PowerAutomate #SharePointOnline or #MicrosoftCopilotStudio content?
Visit my blog, Subscribe to my YouTube channel or Follow me on Twitter


Thank you @Expiscornovus I knew the "Schema Validation" option, but as you wrote in your reply is all about the body of the request not the header.

PerOveSand
Frequent Visitor

You are really asking about something very important here @ID3 . I have been thinking a lot about this lately too. And my first thought was to use logic apps, Azure functions and API management. But the posts and replies here are very good and maybe there is another way. Here are my toughs.

 

The problem is if someone gets the Uri for the flow, they can trigger the flow.

The Uri is built like this:

Url parameters:
?api-version=2016-06-01
&sp=%2Ftriggers%2Fmanual%2Frun
&sv=1.0
&sig=<43 letter random generated secret>
 
If someone copies the trigger Uri and shares it, all of the above needed parameters are shared.
This can be a problem if the person misuses it or shares it with other unknown people.
 
PS! The only way to change the secret code, is to create a new flow. You cannot change the secret code on an existing flow.
 
If attackers does NOT have the URI, they need to guess the workflow GUID and the secret code for the sig parameter. This is extremely unlikely and not really a problem.
 
Risk: Sharing the Uri

An "attacker" needs the Uri for the flow itself to exploit the weakness. 

For this to happen, it requires a person with edit access to the flow and that this person shares the Uri.

Mitigations

  • Securing the edit access to a flow that contains HTTP actions, should be first priority. Use Environments and Solutions, and do not share the owner role of the flow with everyone.
  • You should store the Uri in Azure Key vault. This will stop storing of sensitive values in clear text in the flow definition code.

If these mitigation does not make the risk acceptable, the mitigations below must be evaluated.

 

Trigger Conditions

I really like the article from @Paulie78, since using trigger conditions. It can check the headers and the body for keys and values and act upon them. This is most useful for NOT running the flow at all.

 

Risk: HTTP response giving information back

The high risk is if you do not use the question mark "?" in the condition, it will reply with the value it needs. This actually gives the "attacker" everything it needs.

You need to store the conditions in clear text!

These risk are so bad I would not recommend using them, unless the mitigations in the first risk is acceptable and done. A person with edit access to the flow can expose the information.

The only good reason to use this method is if the condition can check for a non-fakeable value in the header.

Or maybe to just add an extra value that must be shared by a rouge person, making the sharing less intuitive.

 

Mitigations

  • Same mitigations as the risk of sharing the Uri.
  • + Manual and automatic checks for the ? mark in the condition.
  • Use ONLY conditions on header values that cannot be "faked" from the client using the Uri. (Do they exist?) A user agent header can easily be faked.
  • Turn on "Suppress workflow headers" to avoid sending information back to the client.

 

Conditions in Actions

@Expiscornovus suggest a solution using conditions as actions.

This can mitigate the problem with the flow sending secrets to the client as a response.

It will not mitigate the problem stopping an user with edit access to send the needed information.

It will mitigate the risk that secrets are in clear text in the flow definition, since it can pull those secrets from Azure Key Vault.

It will also add a second layer of security check, using a secret that can be changed frequently.

It will not stop an attacker from starting a flow run, consuming runs and causing throttling.

 

I am sure there is more possibilities and that I am missing something to consider. 

 

Please comment and correct me! 🙂

clh
Advocate I
Advocate I

Would there be an option to implement IP restrictions?  I'm not an expert in HTTP, so I don't know.  Is source IP address available in the headers, or some other way that could be used in a trigger condition?

Although, if wanting to restrict to being called from other Power Automates, what is the IP range for MS365/Power Automate as a source?  (I'm thinking, use IP filtering on top of the agent that was mentioned in a previous post.)

zolle04
Advocate II
Advocate II

Helpful resources

Announcements

Community will be READ ONLY July 16th, 5p PDT -July 22nd

Dear Community Members,   We'd like to let you know of an upcoming change to the community platform: starting July 16th, the platform will transition to a READ ONLY mode until July 22nd.   During this period, members will not be able to Kudo, Comment, or Reply to any posts.   On July 22nd, please be on the lookout for a message sent to the email address registered on your community profile. This email is crucial as it will contain your unique code and link to register for the new platform encompassing all of the communities.   What to Expect in the New Community: A more unified experience where all products, including Power Apps, Power Automate, Copilot Studio, and Power Pages, will be accessible from one community.Community Blogs that you can syndicate and link to for automatic updates. We appreciate your understanding and cooperation during this transition. Stay tuned for the exciting new features and a seamless community experience ahead!

Summer of Solutions | Week 4 Results | Winners will be posted on July 24th

We are excited to announce the Summer of Solutions Challenge!    This challenge is kicking off on Monday, June 17th and will run for (4) weeks.  The challenge is open to all Power Platform (Power Apps, Power Automate, Copilot Studio & Power Pages) community members. We invite you to participate in a quest to provide solutions to as many questions as you can. Answers can be provided in all the communities.    Entry Period: This Challenge will consist of four weekly Entry Periods as follows (each an “Entry Period”)   - 12:00 a.m. PT on June 17, 2024 – 11:59 p.m. PT on June 23, 2024 - 12:00 a.m. PT on June 24, 2024 – 11:59 p.m. PT on June 30, 2024 - 12:00 a.m. PT on July 1, 2024 – 11:59 p.m. PT on July 7, 2024 - 12:00 a.m. PT on July 8, 2024 – 11:59 p.m. PT on July 14, 2024   Entries will be eligible for the Entry Period in which they are received and will not carryover to subsequent weekly entry periods.  You must enter into each weekly Entry Period separately.   How to Enter: We invite you to participate in a quest to provide "Accepted Solutions" to as many questions as you can. Answers can be provided in all the communities. Users must provide a solution which can be an “Accepted Solution” in the Forums in all of the communities and there are no limits to the number of “Accepted Solutions” that a member can provide for entries in this challenge, but each entry must be substantially unique and different.    Winner Selection and Prizes: At the end of each week, we will list the top ten (10) Community users which will consist of: 5 Community Members & 5 Super Users and they will advance to the final drawing. We will post each week in the News & Announcements the top 10 Solution providers.  At the end of the challenge, we will add all of the top 10 weekly names and enter them into a random drawing.  Then we will randomly select ten (10) winners (5 Community Members & 5 Super Users) from among all eligible entrants received across all weekly Entry Periods to receive the prize listed below. If a winner declines, we will draw again at random for the next winner.  A user will only be able to win once overall. If they are drawn multiple times, another user will be drawn at random.  Individuals will be contacted before the announcement with the opportunity to claim or deny the prize.  Once all of the winners have been notified, we will post in the News & Announcements of each community with the list of winners.   Each winner will receive one (1) Pass to the Power Platform Conference in Las Vegas, Sep. 18-20, 2024 ($1800 value). NOTE: Prize is for conference attendance only and any other costs such as airfare, lodging, transportation, and food are the sole responsibility of the winner. Tickets are not transferable to any other party or to next year’s event.   ** PLEASE SEE THE ATTACHED RULES for this CHALLENGE**   Week 1 Results: Congratulations to the Week 1 qualifiers, you are being entered in the random drawing that will take place at the end of the challenge.   Community MembersNumber SolutionsSuper UsersNumber Solutions Deenuji 9 @NathanAlvares24  17 @Anil_g  7 @ManishSolanki  13 @eetuRobo  5 @David_MA  10 @VishnuReddy1997  5 @SpongYe  9JhonatanOB19932 (tie) @Nived_Nambiar  8 @maltie  2 (tie)   @PA-Noob  2 (tie)   @LukeMcG  2 (tie)   @tgut03  2 (tie)       Week 2 Results: Congratulations to the Week 2 qualifiers, you are being entered in the random drawing that will take place at the end of the challenge. Week 2: Community MembersSolutionsSuper UsersSolutionsPower Automate  @Deenuji  12@ManishSolanki 19 @Anil_g  10 @NathanAlvares24  17 @VishnuReddy1997  6 @Expiscornovus  10 @Tjan  5 @Nived_Nambiar  10 @eetuRobo  3 @SudeepGhatakNZ 8     Week 3 Results: Congratulations to the Week 3 qualifiers, you are being entered in the random drawing that will take place at the end of the challenge. Week 3:Community MembersSolutionsSuper UsersSolutionsPower Automate Deenuji32ManishSolanki55VishnuReddy199724NathanAlvares2444Anil_g22SudeepGhatakNZ40eetuRobo18Nived_Nambiar28Tjan8David_MA22   Week 4 Results: Congratulations to the Week 4 qualifiers, you are being entered in the random drawing that will take place at the end of the challenge. Week 4:Community MembersSolutionsSuper UsersSolutionsPower Automate Deenuji11FLMike31Sayan11ManishSolanki16VishnuReddy199710creativeopinion14Akshansh-Sharma3SudeepGhatakNZ7claudiovc2CFernandes5 misc2Nived_Nambiar5 Usernametwice232rzaneti5 eetuRobo2   Anil_g2   SharonS2  

Check Out | 2024 Release Wave 2 Plans for Microsoft Dynamics 365 and Microsoft Power Platform

On July 16, 2024, we published the 2024 release wave 2 plans for Microsoft Dynamics 365 and Microsoft Power Platform. These plans are a compilation of the new capabilities planned to be released between October 2024 to March 2025. This release introduces a wealth of new features designed to enhance customer understanding and improve overall user experience, showcasing our dedication to driving digital transformation for our customers and partners.    The upcoming wave is centered around utilizing advanced AI and Microsoft Copilot technologies to enhance user productivity and streamline operations across diverse business applications. These enhancements include intelligent automation, AI-powered insights, and immersive user experiences that are designed to break down barriers between data, insights, and individuals. Watch a summary of the release highlights.    Discover the latest features that empower organizations to operate more efficiently and adaptively. From AI-driven sales insights and customer service enhancements to predictive analytics in supply chain management and autonomous financial processes, the new capabilities enable businesses to proactively address challenges and capitalize on opportunities.    

Updates to Transitions in the Power Platform Communities

We're embarking on a journey to enhance your experience by transitioning to a new community platform. Our team has been diligently working to create a fresh community site, leveraging the very Dynamics 365 and Power Platform tools our community advocates for.  We started this journey with transitioning Copilot Studio forums and blogs in June. The move marks the beginning of a new chapter, and we're eager for you to be a part of it. The rest of the Power Platform product sites will be moving over this summer.   Stay tuned for more updates as we get closer to the launch. We can't wait to welcome you to our new community space, designed with you in mind. Let's connect, learn, and grow together.   Here's to new beginnings and endless possibilities!   If you have any questions, observations or concerns throughout this process please go to https://aka.ms/PPCommSupport.   To stay up to date on the latest details of this migration and other important Community updates subscribe to our News and Announcements forums: Copilot Studio, Power Apps, Power Automate, Power Pages