Restricting Azure App Access - Service Tags and the Crucial FDID

Introduction

Azure Front Door enhances web application delivery in Azure App Service, offering both global load balancing and advanced security features. However, a recurring issue I've noticed is that many organizations rely solely on service tags for access configuration, overlooking the essential access restrictions by using the header x-azure-fdid. This blog highlights this frequent misconfiguration and offers steps towards a safer setup.

The challenge

While Azure Front Door provides a set of well-known IP ranges defined in the AzureFrontDoor.Backend service tag, merely restricting traffic based on this service tag isn't foolproof. If you only use the service tag for restriction, anyone with an Azure Front Door service can set up your web app as a backend, bypassing your intended traffic flow.

The solution

To ensure that only traffic from your specific Azure Front Door instance can access your App Service, you need to use a unique HTTP header that Azure Front Door sends: x-azure-fdid.

Finding the FDID for Azure Front Door

Before diving into the configuration, it's essential to know where you can locate the FDID for your Azure Front Door instance. Here's how:

Log in to the Azure Portal. In the search bar, type "Front Door" and select "Front Door and CDN" from the dropdown. Navigate to your desired Front Door instance. On the Overview page, you'll find the "Front Door ID" section. The ID listed there is your FDID, which you'll use for access restriction.

Configuring Access Restriction through the CLI

az webapp config access-restriction add --resource-group ResourceGroup --name AppName \
  --rule-name "Azure Front Door" --action Allow --priority 200 --service-tag AzureFrontDoor.Backend \
  --http-header x-azure-fdid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Configuring Access Restriction through the Azure Portal

For those who prefer a graphical interface over the command line, Azure Portal provides an intuitive way to set up access restrictions:

  1. Open the App Service
    • Navigate to your desired App Service instance within the Azure Portal.
  2. Go to Networking
    • Within the App Service dashboard, find and select the "Networking" section.
  3. Access Restriction
    • Here, you'll find the "Access restriction" option. Click on it.
  4. Modify Public Access
    • Choose the "Allow public access" option.
    • Set the "Unmatched rule action" to "Deny". This ensures that any request not matching a rule will be denied.
  5. Add a New Rule
    • Click on the "+" or "Add" button to create a new access rule.
      • Name: Enter a descriptive name for the rule.
      • Action: Set this to "Allow".
      • Priority: Provide a priority number for the rule. Lower numbers indicate higher priority.
      • Type: Choose "Service Tag" from the dropdown.
      • Service Tag: Set this to "AzureFrontDoor.Backend".
      • FDID: In the "X-Azure-FDID" field, input the FDID you retrieved from your Azure Front Door instance.

By using the x-azure-fdid header in your access restriction rules, you ensure that only the designated Azure Front Door instance can communicate with your App Service, adding an extra layer of security.

Conclusion

Azure Front Door offers a powerful way to enhance the performance and security of your web applications hosted in Azure App Service. By correctly configuring access restrictions, you can ensure that your application remains secure while benefiting from the global distribution capabilities of Azure Front Door. Always remember, while service tags offer a level of restriction, for a more granular and secure approach, leveraging unique identifiers like the x-azure-fdid header is essential.