Security Best Practices for Azure App Service Web Apps, Part 3

Microsoft’s Azure App Service is a fully managed Platform as a Service for developers that provides features and frameworks to quickly and easily build apps for any platform and any device. In spite of its ease of use, developers still need to keep security in mind because Azure will not take care of every aspect of security. In our first post on this topic, we learned how to configure custom domain names and certificates for web applications developed using Microsoft’s Azure App Service. In our second post, we learned how to enforce HTTPS for web applications developed using Azure App Service.

In today’s post, we will see different application settings available with Azure that can be used to increase the security and availability of the web application.

Recommended application settings

  • Always On: By default Azure unloads the web application if it is idle for some time to save system resources. When a request is received, the web application is loaded again. This increases application response time and may lead to timeouts in some cases. To ensure the application is not unloaded, use the Always On feature, which is included with Basic, Standard, and premium pricing plans.
  • Web Sockets: Enable this only if your application uses the WebSocket protocol. For safety, this protocol is disabled by default.
  • Auto Swap: For standard or premium pricing plans, Azure provides separate deployment slots, “live web apps with their own hostnames,” according to the documentation. An organization can have multiple deployment slots, such as development, staging, and production. Swapping code between two deployment slots can be automated by configuring the Auto Swap This eliminates downtime when deploying a web application.
  • Remote debugging: When enabled, the remote debugger in Visual Studio can be used to connect directly to the web application. By default, remote debugging is disabled. Remember to disable it immediately after troubleshooting is done, or else it will remain enabled for 48 hours. After 48 hours, Azure will automatically disable it.

To configure the preceding settings, follow these steps:

  • Log in to the Azure portal.
  • Navigate to App Services in left navigation pane.
  • Select your web application.
  • Click on Settings and select Application Settings.
  • Enable Always On. Ensure remote debugging is disabled. Decide whether to use Web Sockets and Auto Swap.

Follow this path to the Application Settings section in the Azure portal.

20160517 Azure 3-2

Cross-Origin Resource Sharing (CORS)

CORS allows applications from different domains to interact with your web application.

  • If Allowed Origins is blank, the setting is safe. No other domain can interact with your application. In other words, CORS is not required by your application.
  • If Allowed Origins is set to particular domains, review whether these domains really require access to your application.
  • If Allowed Origins is set to *, it is unsafe. All other domains can interact with your application. Hence, an attacker-controlled domain can also interact with your application.

CORS can be easily configured through the Azure portal. To configure CORS for your web application, follow these steps:

  • Log in to the Azure portal.
  • Navigate to App Services in left navigation pane.
  • Select your web application.
  • Click on Settings and select CORS.
  • Ensure “*” is not mentioned under Allowed Origins. Either blank or required domains should be specified under Allowed Origins.

Follow this path to the CORS settings in the Azure portal.

20160517 Azure 3-2

For more details on application settings for your web application, follow this link from Microsoft.

This blog post was written by Piyush Mittal.

Leave a Comment

six + seven =