Moving an application onto Azure App Service feels like handing a substantial chunk of the security problem straight to Microsoft, and in some genuine ways it actually is. Patching the underlying operating system, physical security of the data centre, and a good deal of platform-level hardening are all handled for you automatically. But the application sitting on top of that platform is still entirely your own responsibility, and that is exactly where most real, exploitable vulnerabilities actually live in practice.
The shared responsibility line
Azure secures the infrastructure beneath everything. You secure everything you build and configure on top of it yourself, and the exact line between those two responsibilities is not always obvious to teams moving fast under real deadline pressure. Authentication logic, input validation, session handling, access control between different customer accounts on the same platform, all of it is still code that your own developers wrote, and none of it gets automatically hardened just because it happens to sit on Microsoft’s infrastructure instead of somewhere you host yourself.
This is exactly why dedicated Azure pen testing needs to look at the application layer specifically and deliberately, rather than simply confirming the platform configuration looks reasonable on paper during a quick review. A tester needs to interact with your app the way a real user or a genuine attacker actually would, checking carefully whether the business logic holds up under the kind of sustained pressure a compliance checklist never really applies to it in the first place.
Where the real gaps show up
Common findings include weak session management left over from an early build, overly permissive cross-origin settings copied straight from a tutorial years ago and never revisited since, and authorisation checks that work fine for the obvious path through the app but quietly fall apart the moment a request comes in through an unexpected route or an unlisted parameter. None of these failures are Azure’s fault in any meaningful way. They are entirely down to how the application itself was actually built and tested before it ever launched.
William Fieldhouse has flagged this exact misconception directly with clients more than once over the years.
“A client once told us they didn’t need a full test because Azure was ‘already secure’ in their words, and within an hour we’d found an authorisation flaw letting one customer view another customer’s invoices in full. The platform had absolutely nothing to do with that particular gap, the application code sitting on top of it did.”
— William Fieldhouse, Director of Aardwolf Security Ltd
That kind of finding tends to land hard precisely because it contradicts a comfortable assumption the whole team had been quietly operating under for months, sometimes years. The platform was doing its own job perfectly well throughout the entire period. The application simply had not been tested with the same rigour that everyone had wrongly assumed the cloud provider was silently handling on their behalf all along.
Test the layer you actually built
Cloud platforms remove a real and meaningful category of operational risk, and that is genuinely valuable in its own right, but they do not remove the need to test what your own developers actually wrote and shipped to production. Combine dedicated Azure testing with a full web application pen testing to cover both layers properly and thoroughly, because the platform was never really the part most likely to let you down in the first place.