At this point I have close to a decade of working with Azure and AWS/GCP and I can confidently say Azure is the worst when it comes to security, objectively.
Performance, "I don't like the portal", service and capacity availability, and such complaints are somewhat subjective or fixable but I deeply believe Microsoft is the most insecure of the cloud giants on a measurable level.
Anyone that is serious about security should just avoid Microsoft, this has honestly been the case since the early '00s at the least.
I think it’s not just the security of the platform itself either that’s measurably worse - it’s also way easier to end up with insane security configurations with the hellscape that is Entra. It all just feels like it’s held together with duct tape.
The deep integration with AD (now Entra) was the strongest selling point for Azure, but it’s also by far the biggest issue with the platform IMO.
There’s also just no consistency in the platform - the CLI for instance has totally different flags and names depending on which sub command you’re using. It’s like this everywhere in Azure.
> There’s also just no consistency in the platform - the CLI for instance has totally different flags and names depending on which sub command you’re using. It’s like this everywhere in Azure.
For all of AWS's faults, one of the reason I really like them is how consistent everything is. There were so many instances where I could correctly guess the right command for the AWS CLI based on how other services worked, I could never do that with GCP or Azure.
I would love to read an article about how AWS ensures this kind of consistency. Given how Azure and GCP both messed this up, it's clearly not a trivial problem (even though it may seem like one)
My favourite pet peeve is that it uses a bunch of indistinguishable random guids, all of which have two names for no discernible reason whatsoever.
So the doco and the UI ends up littered with things like:
PrincipalId (ClientId)
There’s at least six of those and I honestly can’t remember which pairs with which or what the difference is… which I’m sure is security-critical… somehow.
Identity management is a mess on Azure! I still cannot understand the difference between app registrations and enterprise applications, and how they tie into service principals.
They also have a lot of different resources, such as Graph API, Entra ID.
Manage identities are simpler, since they are Azure constructions, so they work more or less like a IAM role. But then you try to use them with Entra ID APIs and things fall apart.
As someone who is greatly motivated to moving off Azure (to onprem, not to another cloud), do you know of any good collection of Azure security issues I could use as 'ammunition'? Would be greatly appreciated!
I have some notes somewhere but unfortunately they don't have citations, these are just some of the vulns they've had in the last couple years:
• Storm-0558 Breach (2023): Chinese hackers exploited a leaked signing key from a crash dump to access U.S. government emails, affecting 60,000+ State Department communications
• Azure OpenAI Service Exploitation (2024): Hackers bypassed AI guardrails using stolen credentials to generate illicit content, leading to Microsoft lawsuits against developers in Iran, UK, and Vietnam
• CVE-2025-21415 (CVSS 9.9): Spoofing vulnerability in Azure AI Face Service allowed authentication bypass and privilege escalation
• CVE-2023-36052: Azure CLI logging flaw exposed plaintext credentials in CI/CD pipelines, risking sensitive data leakage
• Azurescape (2022): Container escape vulnerability enabled cross-tenant access in Azure Container Instances, discovered by Palo Alto Networks
• ChaosDB (2022): Wiz researchers exploited CosmosDB’s Jupyter Notebook integration to access thousands of customer databases including Fortune 500 companies
• Executive Account Takeover Campaign (2024): Phishing campaign compromised 500+ executive accounts via Azure collaboration tools with MFA manipulation
If your company or workplace is considering migrating from cloud to on-prem or from one cloud to another, I do this professionally btw, feel free to reach out at this temporary email and we can chat: pale.pearl2178 at fastmail.com (to prevent my real email being scraped from HN).
Security issues/CVEs should never be used as a motivation to get off of a particular platform, otherwise we'd never use Linux, macOS, or Windows (I hope you're a fan of OpenBSD... sometimes).
If these issues remain unfixed after being disclosed, or a pattern of fixes that took much longer than you feel they should have, that's valuable ammunition as it shows the organization isn't responsive to security issues.
They’ve improved a lot, but their Achilles heel used to be that the only way they could achieve more challenging compliance requirements was to have multiple segmented clouds.
With Office 365, for example, they had at least 4 government clouds, some of which used shared infrastructure with Azure commercial, but had different data residency or employee requirements. They have thousands of employees monitored by all of the states as a condition of working on those clouds, for example.
Technical controls are similar, but the weak point are things that can cross cloud boundaries. One of the Chinese breaches of US government systems were caused by a PKI vulnerability that allowed the attacker to pivot from a dev environment to a federal cloud instance.
Not strictly security, but there are several long-standing issues with Azure DevOps build pipelines and Artifacts feeds. Using a private artifact feed in your pipeline inexplicably adds minutes to the amount of time it takes to restore packages. And publishing C# NuGet packages together with the source/symbol files is a poorly supported and poorly documented mess (it doesn't help that NuGet support in the dotnet CLI is missing support for important and long requested features only available by using the full fat NuGet client or MSBuild directly).
Not surprised, given its ancestry. This isn't a critique, so much as an observation.
Microsoft's corporate culture evolved during some two decades under a very different threat model & security posture. A lot of the platform's foundations originate from that era, and although they've made significant strides you still see some of their other products struggle in this aspect as well (eg. good security primitives are there but they're sloppy in their default configuration and intuitability). Compare it to a platform that spent its youth growing up in a more actively hostile environment (like Bitcoin).
Another reason to be worried by Microsoft’s Azure security guidelines which state “Identity is the new perimeter”.
Well, the perimeter is not a gate but a cattle guard, and I am not surprised to see some wolves eating a secret and a cow swaggering into the road.
Azure service APIs have always conflated the principles of “reachability from the public internet” and “anonymous access” into a single concept called “Public Access” which, for Azure KV, has 6 different public/private configuration combinations!
This vulnerability report did not include the Key Vault Networking settings for “Public network access”, so more testing (but not much more) is needed to see if the proxy side door can circumvent a resource ACL or private endpoint or both.
It's not just "identity", but "authorization". Really, what they mean is "defense in depth" minus firewalls (because the "in depth" part makes those less relevant), I think. And... that is a reasonable position... provided you get the "in depth" part right, which includes not having proxies that bypass authorization.
Binary Security found the undocumented APIs for Azure API Connections. In this post we examine the inner workings of the Connections allowing us to escalate privileges and read secrets in backend resources for services ranging from Key Vaults, Storage Blobs, Defender ATP, to Enterprise Jira and SalesForce servers.
>The Connector for Key Vaults is maybe the one with the highest impact.
Yeah, no joke. Considering how well protected Azure Key Vaults typically are, and what's in them (secrets, certificates etc) this is huge way to compromise a lot of other things. It's finding the keys to the doors.
Well at the bottom of the article, they mention that Microsoft first closed the issue as invalid, and on the second attempt they closed it as "cannot be reproduced" (after fixing it).
I'm no security expert, but this seems like a bad take. How are APIs any less secure than any other form of interacting with a program? Nothing here is really a problem with APIs but rather a problem with access control.
> anyone with Reader permissions on the connection is allowed to arbitrarily call any endpoint on the connection
This is not an API issue... It feels like saying we shouldn't allow users to search a database because they might run a SQL injection to drop all the tables. Searching tables isn't the problem, not sanitizing inputs is. This is more like giving all users on your network sudo access or just doing chmod -R 777 /.
My concern here is that a lot of people have the takeaway that APIs shouldn't be exposed because they create security risks. But that's not true. The API exposure isn't the risk, it is the access control. If you don't have proper access control then it really isn't going to matter if you have an API or not. But then again, we have a long history of not taking fairly basic security seriously and with decades of computing and seeing the results, I really can't figure out why. Sure, security is expensive, but bad security is far more expensive. I guess maybe the issue is I'm not much of a gambler.
I think you misunderstood what was meant by "API connections". In azure, they're an entity that is created to represent connectivity to some external service, usually bundled with credentials and the OpenAPI definition of the downstream service. They let you consume an external service from other azure services without having to worry about things like token refresh. The article goes into better detail on this than I can in a comment.
Maybe with enough traction, they'll lose out on huge contracts because of stuff like this. Seems the only way to get stuff fixed is to attach dollars to it.
At this point I have close to a decade of working with Azure and AWS/GCP and I can confidently say Azure is the worst when it comes to security, objectively.
Performance, "I don't like the portal", service and capacity availability, and such complaints are somewhat subjective or fixable but I deeply believe Microsoft is the most insecure of the cloud giants on a measurable level.
Anyone that is serious about security should just avoid Microsoft, this has honestly been the case since the early '00s at the least.
I think it’s not just the security of the platform itself either that’s measurably worse - it’s also way easier to end up with insane security configurations with the hellscape that is Entra. It all just feels like it’s held together with duct tape.
The deep integration with AD (now Entra) was the strongest selling point for Azure, but it’s also by far the biggest issue with the platform IMO.
There’s also just no consistency in the platform - the CLI for instance has totally different flags and names depending on which sub command you’re using. It’s like this everywhere in Azure.
> There’s also just no consistency in the platform - the CLI for instance has totally different flags and names depending on which sub command you’re using. It’s like this everywhere in Azure.
For all of AWS's faults, one of the reason I really like them is how consistent everything is. There were so many instances where I could correctly guess the right command for the AWS CLI based on how other services worked, I could never do that with GCP or Azure.
I would love to read an article about how AWS ensures this kind of consistency. Given how Azure and GCP both messed this up, it's clearly not a trivial problem (even though it may seem like one)
My favourite pet peeve is that it uses a bunch of indistinguishable random guids, all of which have two names for no discernible reason whatsoever.
So the doco and the UI ends up littered with things like:
There’s at least six of those and I honestly can’t remember which pairs with which or what the difference is… which I’m sure is security-critical… somehow.Identity management is a mess on Azure! I still cannot understand the difference between app registrations and enterprise applications, and how they tie into service principals.
They also have a lot of different resources, such as Graph API, Entra ID.
Manage identities are simpler, since they are Azure constructions, so they work more or less like a IAM role. But then you try to use them with Entra ID APIs and things fall apart.
As someone who is greatly motivated to moving off Azure (to onprem, not to another cloud), do you know of any good collection of Azure security issues I could use as 'ammunition'? Would be greatly appreciated!
UPD: note to self - this seems like a good resource https://www.cloudvulndb.org/results
I have some notes somewhere but unfortunately they don't have citations, these are just some of the vulns they've had in the last couple years:
• Storm-0558 Breach (2023): Chinese hackers exploited a leaked signing key from a crash dump to access U.S. government emails, affecting 60,000+ State Department communications
• Azure OpenAI Service Exploitation (2024): Hackers bypassed AI guardrails using stolen credentials to generate illicit content, leading to Microsoft lawsuits against developers in Iran, UK, and Vietnam
• CVE-2025-21415 (CVSS 9.9): Spoofing vulnerability in Azure AI Face Service allowed authentication bypass and privilege escalation
• CVE-2023-36052: Azure CLI logging flaw exposed plaintext credentials in CI/CD pipelines, risking sensitive data leakage
• Azurescape (2022): Container escape vulnerability enabled cross-tenant access in Azure Container Instances, discovered by Palo Alto Networks
• ChaosDB (2022): Wiz researchers exploited CosmosDB’s Jupyter Notebook integration to access thousands of customer databases including Fortune 500 companies
• Executive Account Takeover Campaign (2024): Phishing campaign compromised 500+ executive accounts via Azure collaboration tools with MFA manipulation
If your company or workplace is considering migrating from cloud to on-prem or from one cloud to another, I do this professionally btw, feel free to reach out at this temporary email and we can chat: pale.pearl2178 at fastmail.com (to prevent my real email being scraped from HN).
Security issues/CVEs should never be used as a motivation to get off of a particular platform, otherwise we'd never use Linux, macOS, or Windows (I hope you're a fan of OpenBSD... sometimes).
If these issues remain unfixed after being disclosed, or a pattern of fixes that took much longer than you feel they should have, that's valuable ammunition as it shows the organization isn't responsive to security issues.
They’ve improved a lot, but their Achilles heel used to be that the only way they could achieve more challenging compliance requirements was to have multiple segmented clouds.
With Office 365, for example, they had at least 4 government clouds, some of which used shared infrastructure with Azure commercial, but had different data residency or employee requirements. They have thousands of employees monitored by all of the states as a condition of working on those clouds, for example.
Technical controls are similar, but the weak point are things that can cross cloud boundaries. One of the Chinese breaches of US government systems were caused by a PKI vulnerability that allowed the attacker to pivot from a dev environment to a federal cloud instance.
Not strictly security, but there are several long-standing issues with Azure DevOps build pipelines and Artifacts feeds. Using a private artifact feed in your pipeline inexplicably adds minutes to the amount of time it takes to restore packages. And publishing C# NuGet packages together with the source/symbol files is a poorly supported and poorly documented mess (it doesn't help that NuGet support in the dotnet CLI is missing support for important and long requested features only available by using the full fat NuGet client or MSBuild directly).
Azure requires that you use SHA-1 RSA private keys for initially connecting to VMs.
We just migrated off Azure after one to many deprecation or downtimes caused by some random new feature or change of how permissions work. We gave up.
Not surprised, given its ancestry. This isn't a critique, so much as an observation.
Microsoft's corporate culture evolved during some two decades under a very different threat model & security posture. A lot of the platform's foundations originate from that era, and although they've made significant strides you still see some of their other products struggle in this aspect as well (eg. good security primitives are there but they're sloppy in their default configuration and intuitability). Compare it to a platform that spent its youth growing up in a more actively hostile environment (like Bitcoin).
Another reason to be worried by Microsoft’s Azure security guidelines which state “Identity is the new perimeter”.
Well, the perimeter is not a gate but a cattle guard, and I am not surprised to see some wolves eating a secret and a cow swaggering into the road.
Azure service APIs have always conflated the principles of “reachability from the public internet” and “anonymous access” into a single concept called “Public Access” which, for Azure KV, has 6 different public/private configuration combinations!
This vulnerability report did not include the Key Vault Networking settings for “Public network access”, so more testing (but not much more) is needed to see if the proxy side door can circumvent a resource ACL or private endpoint or both.
It's not just "identity", but "authorization". Really, what they mean is "defense in depth" minus firewalls (because the "in depth" part makes those less relevant), I think. And... that is a reasonable position... provided you get the "in depth" part right, which includes not having proxies that bypass authorization.
Binary Security found the undocumented APIs for Azure API Connections. In this post we examine the inner workings of the Connections allowing us to escalate privileges and read secrets in backend resources for services ranging from Key Vaults, Storage Blobs, Defender ATP, to Enterprise Jira and SalesForce servers.
>The Connector for Key Vaults is maybe the one with the highest impact.
Yeah, no joke. Considering how well protected Azure Key Vaults typically are, and what's in them (secrets, certificates etc) this is huge way to compromise a lot of other things. It's finding the keys to the doors.
That’s a scary vulnerability. There’s no mention of the bug bounty paid out for it but I hope it was substantial.
Well at the bottom of the article, they mention that Microsoft first closed the issue as invalid, and on the second attempt they closed it as "cannot be reproduced" (after fixing it).
So from that I can imply there was no payment.
It's a feature not a bug: "Azure’s Security Vulnerabilities Are Out of Control" - https://www.lastweekinaws.com/blog/azures_vulnerabilities_ar...
The caller still needs at least the Reader role, so it was limited to accounts that were added to the Azure subscription as only Readers.
I'm glad they fixed it, but this doesn't seem too scary??
My concern here is that a lot of people have the takeaway that APIs shouldn't be exposed because they create security risks. But that's not true. The API exposure isn't the risk, it is the access control. If you don't have proper access control then it really isn't going to matter if you have an API or not. But then again, we have a long history of not taking fairly basic security seriously and with decades of computing and seeing the results, I really can't figure out why. Sure, security is expensive, but bad security is far more expensive. I guess maybe the issue is I'm not much of a gambler.
I think you misunderstood what was meant by "API connections". In azure, they're an entity that is created to represent connectivity to some external service, usually bundled with credentials and the OpenAPI definition of the downstream service. They let you consume an external service from other azure services without having to worry about things like token refresh. The article goes into better detail on this than I can in a comment.
So this was vulnerable ? https://azure.microsoft.com/en-us/explore/global-infrastruct...
Maybe with enough traction, they'll lose out on huge contracts because of stuff like this. Seems the only way to get stuff fixed is to attach dollars to it.
Oh a confuse delegate vulnerability. Azure is not the only cloud provider with that oversight, let me tell you.