You may have faced some issues while securing App Services behind an Azure Application Gateway.
More often than not, these issues are not really caused due to problems with the App Service or Application Gateway itself, but with the way the configuration & functioning of these products/services are interpreted.
In this blog post, I'm calling out one such scenario where redirects configured at the App Service web.config, end up exposing *.azurewebsites.net to the client (for example, on the browser's address bar)
Custom Domain (www.customdomain.com) has a C-Name to Application Gateway’s default domain (*.cloudapp.net).
Application Gateway has App Service Configured as the Backend Pool.
Probes & listeners are in place for the App Service Backend Pool.
Backend App Service has rewrite rules configured. (Say, HTTP to HTTPS)
When a request is made to the Application Gateway’s Custom Domain name (www.customdomain.com) –> appname.azurewebsites.net is exposed on the browser.
WHY IS THIS AN ISSUE?
One of the main intentions for customers to use Application Gateway in front of App Service is to avoid exposing the backend application’s whereabouts to the end user.
However, the scenario addressed here defeats the purpose of the Application Gateway.