Security in Azure App Service
This article shows you how Azure App Service helps secure your web app, mobile app back end, API app, and function app. It also shows how you can further secure your app with the built-in App Service features.
The platform components of App Service, including Azure VMs, storage, network connections, web frameworks, management and integration features, are actively secured and hardened. App Service goes through vigorous compliance checks on a continuous basis to make sure that:
- Your app resources are secured from the other customers' Azure resources.
- VM instances and runtime software are regularly updated to address newly discovered vulnerabilities.
- Communication of secrets (such as connection strings) between your app and other Azure resources (such as SQL Database) stays within Azure and doesn't cross any network boundaries. Secrets are always encrypted when stored.
- All communication over the App Service connectivity features, such as hybrid connection, is encrypted.
- Connections with remote management tools like Azure PowerShell, Azure CLI, Azure SDKs, REST APIs, are all encrypted.
- 24-hour threat management protects the infrastructure and platform against malware, distributed denial-of-service (DDoS), man-in-the-middle (MITM), and other threats.
For more information on infrastructure and platform security in Azure, see Azure Trust Center.
The following sections show you how to further protect your App Service app from threats.
HTTPS and Certificates
App Service lets you secure your apps with HTTPS. When your app is created, its default domain name (<app_name>.azurewebsites.net) is already accessible using HTTPS. If you configure a custom domain for your app, you should also secure it with a custom certificate so that client browsers can make secured HTTPS connections to your custom domain. There are two ways to do it:
- App Service certificate - Create a certificate directly in Azure. The certificate is secured in Azure Key Vault, and can be imported into your App Service app. For more information, see Buy and Configure an SSL Certificate for your Azure App Service.
- Third-party certificate - Upload a custom SSL certificate that you purchased from a trusted certificate authority and bind it to your App Service app. App Service supports both single-domain certificates and wildcard certificates. It also supports self-signed certificates for testing purposes. For more information, see Bind an existing custom SSL certificate to Azure App Service.
Insecure protocols (HTTP, TLS 1.0, FTP)
To secure your app against all unencrypted (HTTP) connections, App Service provides one-click configuration to enforce HTTPS. Unsecured requests are turned away before they even reach your application code. For more information, see Enforce HTTPS.
App Service supports both FTP and FTPS for deploying your files. However, FTPS should be used instead of FTP, if at all possible. When one or both of these protocols are not in use, you should disable them.
Static IP restrictions
By default, your App Service app accepts requests from all IP addresses from the internet, but you can limit that access to a small subset of IP addresses. App Service on Windows lets you define a list of IP addresses that are allowed to access your app. The allowed list can include individual IP addresses or a range of IP addresses defined by a subnet mask. For more information, see Azure App Service Static IP Restrictions.
For App Service on Windows, you can also restrict IP addresses dynamically by configuring the web.config. For more information, see Dynamic IP Security <dynamicIpSecurity>.
Client authentication and authorization
Azure App Service provides turn-key authentication and authorization of users or client apps. When enabled, it can sign in users and client apps with little or no application code. You may implement your own authentication and authorization solution, or allow App Service to handle it for you instead. The authentication and authorization module handles web requests before handing them off to your application code, and it denies unauthorized requests before they reach your code.
App Service authentication and authorization support multiple authentication providers, including Azure Active Directory, Microsoft accounts, Facebook, Google, and Twitter. For more information, see Authentication and authorization in Azure App Service.
When authenticating against a back-end service, App Service provides two different mechanisms depending on your need:
- Service identity - Sign in to the remote resource using the identity of the app itself. App Service lets you easily create a managed identity, which you can use to authenticate with other services, such as Azure SQL Database or Azure Key Vault. For an end-to-end tutorial of this approach, see Secure Azure SQL Database connection from App Service using a managed identity.
- On-behalf-of (OBO) - Make delegated access to remote resources on behalf of the user. With Azure Active Directory as the authentication provider, your App Service app can perform delegated sign-in to a remote service, such as Azure Active Directory Graph API or a remote API app in App Service. For an end-to-end tutorial of this approach, see Authenticate and authorize users end-to-end in Azure App Service.
Connectivity to remote resources
There are three types of remote resources your app may need to access:
In each of these cases, App Service provides a way for you to make secure connections, but you should still observe security best practices. For example, always use encrypted connections even if the back-end resource allows unencrypted connections. Furthermore, make sure that your back-end Azure service allows the minimum set of IP addresses. You can find the outbound IP addresses for your app at Inbound and outbound IP addresses in Azure App Service.
When your app connects to Azure resources, such as SQL Database and Azure Storage, the connection stays within Azure and doesn't cross any network boundaries. However, the connection goes through the shared networking in Azure, so always make sure that your connection is encrypted.
If your app is hosted in an App Service environment, you should connect to supported Azure services using Virtual Network service endpoints.
Resources inside an Azure Virtual Network
Your app can access resources in an Azure Virtual Network through Virtual Network integration. The integration is established with a Virtual Network using a point-to-site VPN. The app can then access the resources in the Virtual Network using their private IP addresses. The point-to-site connection, however, still traverses the shared networks in Azure.
To isolate your resource connectivity completely from the shared networks in Azure, create your app in an App Service environment. Since an App Service environment is always deployed to a dedicated Virtual Network, connectivity between your app and resources within the Virtual Network is fully isolated. For other aspects of network security in an App Service environment, see Network isolation.
You can securely access on-premises resources, such as databases, in three ways:
- Hybrid connections - Establishes a point-to-point connection to your remote resource through a TCP tunnel. The TCP tunnel is established using TLS 1.2 with shared access signature (SAS) keys.
- Virtual Network integration with site-to-site VPN - As described in Resources inside an Azure Virtual Network, but the Virtual Network can be connected to your on-premises network through a site-to-site VPN. In this network topology, your app can connect to on-premises resources like other resources in the Virtual Network.
- App Service environment with site-to-site VPN - As described in Resources inside an Azure Virtual Network, but the Virtual Network can be connected to your on-premises network through a site-to-site VPN. In this network topology, your app can connect to on-premises resources like other resources in the Virtual Network.
Don't store application secrets, such as database credentials, API tokens, and private keys in your code or configuration files. The commonly accepted approach is to access them as environment variables using the standard pattern in your language of choice. In App Service, the way to define environment variables is through app settings (and, especially for .NET applications, connection strings). App settings and connection strings are stored encrypted in Azure, and they're decrypted only before being injected into your app's process memory when the app starts. The encryption keys are rotated regularly.
Alternatively, you can integrate your App Service app with Azure Key Vault for advanced secrets management. By accessing the Key Vault with a managed identity, your App Service app can securely access the secrets you need.
Except for the Isolated pricing tier, all tiers run your apps on the shared network infrastructure in App Service. For example, the public IP addresses and front-end load balancers are shared with other tenants. The Isolated tier gives you complete network isolation by running your apps inside a dedicated App Service environment. An App Service environment runs in your own instance of Azure Virtual Network. It lets you:
- Serve your apps through a dedicated public endpoint, with dedicated front ends.
- Serve internal application using an internal load balancer (ILB), which allows access only from inside your Azure Virtual Network. The ILB has an IP address from your private subnet, which provides total isolation of your apps from the internet.
- Use an ILB behind a web application firewall (WAF). The WAF offers enterprise-level protection to your public-facing applications, such as DDoS protection, URI filtering, and SQL injection prevention.
For more information, see Introduction to Azure App Service Environments.