Not many developers know there is a big security risk that Power Automate Developers could fall fowl of.

The security issue is all around how the Power Platform handles credentials, with each user/owner signing in and storing their credentials in connections.

This has its strengths, as all credentials are securely stored and accessing apps/ running flows is easy as the Power Platform handles everything. The problem comes when you share flows, as what you might not realise is you are sharing your connections (aka credentials) with that user.

They may not be able to see your credentials, but that doesn't mean they cant use them in a way that you didn't want. And what's worse is there is no granularity in connections, so an Outlook connection used for reading events can be used to delete emails.

The good news is Microsoft recently started to warn you when you shared connections.

And although I see Microsoft doing more in the future, for now its note quite enough, because:

• If you don't read these warnings (which people don't especially when it looks like more Terms & Conditions then warnings)
• Legacy shares
• No easy alternatives (Requires Service Accounts, often not easily accessible for citizen developers)

Before we can avoid it we need to know how, so exactly how could I get hacked if I share a flow.

The first thing to say is the hack is a lot more likely if you share Outlook connection, and this is because the owner only gets notified of changes through email. Though this does not mitigate all risk as depending on when the changes are made the owner might not get chance to see the changes (there is no version control and run logging is limited to last 100 runs).

Lets start with a simple flow that is triggered on a email to shared mailbox, it does something with the email and ends.

This sounds like an example of a flow that would be shared as its a shared mailbox so a team most likely relies on it.

Once I have shared owner rights I can see and use the owners connections, so if I wanted to I could delete the Shared Mailbox trigger and use the personal email arrives.

But why would I change the trigger to When a new email arrives (V3), well that's because the only warning the owner gets of changes is an email. So if we changed the trigger to the owners mailbox, we can intercept that email, delete it and use it as a trigger for other actions we want to do.

So all we would need to do is add a subject condition (contains "{Your name} has changed a shared flow" ), delete the email and we can then do anything we like with the owners Outlook connections.

In this example I could be reading all your recent 10 emails or send an email to anyone impersonating you/your approval.

If Im smart I would save all the original flow behind a terminate so that I can easily revert back to the original flow.

There are a few things you would have to deal with e.g:

• Ensuring the owner didn't see the change email before being deleted (make sure out of office),
• Explain the last change email that gets through (ie make a simple change to a note)
• Clear the logs (send 100 test emails)

and more, but they can be overcome with a little thought.

So how do we protect ourselves and avoid being hacked:

1 Dont share flows unless you really have to.

• Use send a copy or a flow that can be shared as a run only user (as that requires their credentials)
• Use Service Accounts

2 Minmalise Connections, so don't include additional unnecessary connections in any flow you make

• e.g. Add a teams connection as a exception handler when you could use Outlook connectors that is already part of the flow

3 Set an Outlook rule to copy Flow change emails to another folder. As long as its a server side rule it will run before the flow gets chance to delete it, this way if you ever find an email only in the copy folder you know that's a flag someone is up to no good.