Edit

Prevent subdomain takeovers in Azure App Service

Subdomain takeovers are a common threat for organizations that regularly create and delete many resources. A subdomain takeover can occur when you have a DNS record that points to a deprovisioned Azure resource. Such DNS records are also known as "dangling DNS" entries. Subdomain takeovers allow malicious actors to redirect traffic intended for an organization’s domain to a site performing malicious activity.

The risks of subdomain takeover include:

  • Loss of control over the content of the subdomain
  • Cookie harvesting from unsuspecting visitors
  • Phishing campaigns
  • Further risks of classic attacks such as XSS, CSRF, or CORS bypass

To learn more about subdomain takeover, see Prevent dangling DNS entries and avoid subdomain takeover.

Azure App Service provides name reservation, domain verification tokens, and secure unique default hostnames to prevent subdomain takeovers.

The most effective way to protect your App Service resources from subdomain takeover is to use secure unique default hostnames. This feature is generally available for Web Apps, Function Apps, and Logic Apps (Standard).

When you enable secure unique default hostnames, your app receives a default hostname that includes a randomized hash and a region identifier, making it unique to your organization. This format ensures that no one outside your organization can create a resource with the same default hostname, which eliminates the risk of subdomain takeover through dangling DNS entries.

How it works

Traditional App Service resources use a default hostname format that is globally predictable:

Global (original) Unique (new)
Default hostname <AppName>.azurewebsites.net <AppName>-<Hash>.<Region>.azurewebsites.net
SCM endpoint <AppName>.scm.azurewebsites.net <AppName>-<Hash>.scm.<Region>.azurewebsites.net

For example, a web app named contoso deployed to East US might receive:

contoso-a6gqaeashthkhkeu.eastus-01.azurewebsites.net

The 16-character hash is deterministic within a configurable scope, so you can ensure consistent hostnames across environments when needed.

Hash scope options

When you create a resource with a unique default hostname, you choose a scope that determines how the hash is generated:

Scope Description
Tenant Reuse Same hash for the same app name across all subscriptions in your Microsoft Entra tenant.
Subscription Reuse Same hash for the same app name within the same subscription.
Resource Group Reuse Same hash for the same app name within the same resource group.
No Reuse Unique hash every time. Maximum isolation.

Tip

If you regularly redeploy resources across environments (for example, from a test subscription to a production subscription under the same tenant), use Tenant Reuse to ensure your hostnames remain consistent across subscriptions.

Deployment slots

Deployment slots follow the same format as the production site, but each slot receives its own distinct hash:

Default hostname Slot hostname
Format <AppName>-<Hash>.<Region>.azurewebsites.net <AppName>-<SlotName>-<Hash>.<Region>.azurewebsites.net

Slots are always created with the same scope as the production site.

How to enable

You configure secure unique default hostnames when you create the resource. You can't apply them to existing resources retroactively. The way you enable them depends on the client you use:

  • Azure portal: New Web Apps, Function Apps, and Logic Apps (Standard) created in the Azure portal use secure unique default hostnames automatically on all supported SKUs. No extra configuration is required.
  • Azure CLI, ARM templates, and REST API: You must opt in explicitly by setting the hostname scope on the create request. Set this value for every new deployment so that resources created outside the portal use the same default hostname format as resources created in the portal.

Use the --domain-name-scope parameter when creating a new resource to enable secure unique default hostnames.

Resource type Command Reference
Web Apps az webapp create --name <AppName> --resource-group <ResourceGroup> --plan <AppServicePlan> --domain-name-scope TenantReuse az webapp create
Function Apps az functionapp create --name <AppName> --resource-group <ResourceGroup> --storage-account <StorageAccount> --consumption-plan-location <Region> --domain-name-scope TenantReuse az functionapp create
Logic Apps (Standard) az logicapp create --name <AppName> --resource-group <ResourceGroup> --storage-account <StorageAccount> --domain-name-scope TenantReuse az logicapp create

The --domain-name-scope parameter accepts the following values: NoReuse, ResourceGroupReuse, SubscriptionReuse, TenantReuse.

Migrating existing resources

Since this feature can only be enabled at creation time, you have two options for existing resources:

  • Clone a pre-existing app to a new app with secure unique default hostnames enabled.
  • Restore from a backup to a new app with secure unique default hostnames enabled.

Both options are available in the Azure portal.

Why adopt this now

Secure unique default hostnames provide protection by default. Unlike other mitigation strategies that require ongoing DNS hygiene and manual intervention, this approach builds security directly into the hostname structure. When enabled:

  • No external actor can recreate your default hostname.
  • Dangling DNS entries can't be exploited for subdomain takeover.
  • No additional configuration steps are needed beyond enabling the feature at creation time.

Use secure unique default hostnames for every new App Service deployment. The Azure portal already applies this configuration automatically for new resources on supported SKUs. Aligning your Azure CLI, ARM template, and REST API deployments with the same default hostname format keeps your provisioning consistent with the recommended App Service configuration.

Note

The region identifier in the hostname (for example, eastus-01) may use different number suffixes for future deployments. Don't take hard dependencies on the exact region-number combination.

Related content

How App Service prevents subdomain takeovers

Upon deletion of an App Service app or App Service Environment (ASE), the corresponding DNS is forbidden from reuse except by subscriptions that belong to the tenant of the subscription that originally owned the DNS. Thus, the customer has some time to either clean up any associations or pointers to the said DNS or reclaim the DNS in Azure by recreating the resource with the same name. This behavior is enabled by default on Azure App Service for *.azurewebsites.net and *.appserviceenvironment.net resources, so it doesn't require any customer configuration.

Example scenario

Subscription A and subscription B are the only subscriptions that belong to tenant AB. Subscription A contains an App Service web app test with DNS name test.azurewebsites.net. Upon deletion of the app, only subscriptions A or B are able to immediately reuse the DNS name test.azurewebsites.net by creating a web app named test. No other subscriptions are allowed to claim the name right after the resource deletion.

How you can prevent subdomain takeovers

When creating DNS entries for Azure App Service, create an asuid.{subdomain} TXT record with the domain verification ID. When such a TXT record exists, no other Azure subscription can validate the custom domain or take it over unless they add their token verification ID to the DNS entries.

These records prevent the creation of another App Service app using the same name from your CNAME entry. Without the ability to prove ownership of the domain name, threat actors can't receive traffic or control the content.

DNS records should be updated before the site deletion to ensure bad actors can't take over the domain between the period of deletion and re-creation.

To get a domain verification ID, see Set up an existing custom domain in Azure App Service.

  • Last updated on