Incoming Webhook security
So far, I've not found any information on the topic of incoming webhook and actionable messages security, specifically - I'd love to be able to have any authorization required to post to the incoming webhook or limit the possible Actionable Message url target to just my company domain. Right now, I am afraid that if the incoming webhook address leaks outside the company, someone will be able to send Actionable Message form, which will send sensitive info outside of my company.
Mihai Badila commented
Any update for this? Our company does not allow to have this functionality because is not secured.
Upvote on this. Its holding us back on migrating from Slack.
Mat Williamson commented
This is a hot topic for us - we really want to use Teams for chatops but this weakness holds our teams back - would love to see this feature done.
Justin Chase commented
My company blocks the use of webhooks for this reason. The webhook needs to accept authentication tokens.
Also hoping for a fix for this. The alternative integration for outside services of creating an authenticated bot that monitors some custom API is a lot more difficult. I think this solution creates more problems than it solves. The documentation statement that JSON payloads are not dangerous is in itself false. More importantly, Teams takes that payload and injects it into Teams unauthenticated. Anyone with with that URL could inject malicious URLs into an orgs chat. How many users even vet their emails? You think they will think twice about clicking a link on a private Teams channel?
Since the webhook URL is hosted by Microsoft anyways, how about authentication options via AAD?
Pankaj Sharma commented
So .. what is the best way at this point to secure your incoming webhook in MS Teams? Is the only way is to keep the webhook URL a secret?
We had to pull this from the apps policies due to this security risk. I am doing my checks if this could be stopped at the peripherals at Firewall. But this must be addressed at the app level and it should work more of a delegated permission way and must be able to have additional security configuration as well.
Incoming Webhooks are almost unusable without any authentication in place. Apparently the whole security relies on keeping the URL secret. This might be enough for sharing pictures in the internet but not for enterprise applications. Please follow the guidelines from other players, e.g., GitHub or Twitter.
The official documentation states the following: "Messages are formatted as JSON payloads. This declarative messaging structure prevents the injection of malicious code as there is no code execution on the client."
That's a false assumption. Please study the CVE databases more closely. There are hundreds of know vulnerabilities and attack vectors based on JSON or similar payloads. The security concept should be fundamentally re-evaluated.
This is huge security risk and we want it to be addressed
Pascal Auregan commented
I can't get why it is not solved yet ? Is there something we're missing ? I'd like more security on webhooks too like allowed pushers or technical auth. Thanks
Matthias Kirsch commented
Any News on this topic? Thx!
Hello ! When can we have information about amelioration on this feature ? We need to add this in our organization (20000 users) and it's blocked by security department because it opens a anonymous acces on our organization. We can't survey posts on webhook, we can't have audit log on this, and we can't restrict its use on some user account's.
It's unusable and it's frustrating for teams who needs this feature.
Please increase security on this component !
Pankaj Sharma commented
Hey - any information around this!
Do we know how to secure incoming webhooks on MS Teams yet? This really makes the webhook unusable if it not secure.
Bradley Stein commented
We also cannot find if there is ANY way to secure an incoming web-hook.
In theory, this means that the security hole here is somewhere between a nuclear bomb and a universe destroying black hole.
Can someone from MS chime in as to whether it is even possible to secure an incoming web-hook so that you can control who is allowed to call it.
When it will be addressed?