When you deploy a Azure Front Door (or CDN) service usually you need to protect (with WAF) or you need to offload traffic from your workload – you point users to WAF/CDN url instead of origin (your workload) url. Thanks that you can protect any origin from App Service, Static website (deployed in Storage Account) or another custom origin (e.g. Kubernetes container or some on-prem workload).

Risks for Origin in Public Endpoint Model

Main issue what comes up with this model is restricting the origin to be called by WAF/CDN only – an attacker is able to call origin directly and bypass any WAF protection and perform a SQL injection or DDoS attack on your workload. You could protect your workload by filtering traffic on your backend only, based on HTTP header X-Azure-FDID value (you can find more details here) and whitelisting Azure’s infrastructure IP range (be careful about this option – IP range could change in future – you need to monitor Azure Service Tag AzureFrontDoor.Backend for any changes).

Your workload would stay exposed to public internet and could be vulnerable against attacks with network vectors, but at least there are some security controls in place.

Securing Origin with Private Link

In February 2021 Microsoft introduced a game changer feature – Azure Private Link integration for Front Door.

What is Private Link?

Azure Private Link enables you to access Azure PaaS Services (for example, Azure Storage and SQL Database) and Azure hosted customer-owned/partner services over a private endpoint in your virtual network.

Traffic between your workload and service is not routed via public internet, but via Microsoft private network (backbone) only. Thanks to that your workload can access required service via much more secure way and doesn’t have to be exposed to internet (but they can be if you need).

Private Link is also good option versus IP whitelist filtering, because with private endpoint you associate (whitelist) your workload with a instance, not whole PaaS service.

Additional advantage of Private Link is, that your workload can be even in another subscription, even in another AAD tenant.

How to Secure Static Website Origin on Azure Storage Account

Turn On Static Website Feature

For deployment of SPA websites (or static export from WordPress, see my previous article PR Crisis Microsite Deployed in Cloud in Few Hours). I prefer to deploy these files into Azure Blob Storage with turned on Static Website feature.

When you turn on the feature, your will receive an auto-generated URL for your storage account – we will need this URL later.

Anything, what you upload into blob storage folder $web, will be accessible over this auto-generated URL.

Restrict Public Access for Azure Storage

Go to Networking and restrict access to selected networks only. You can also uncheck Allow trusted Microsoft services to access to storage account option.

Set Up Origin in Azure Front Door

As next you need to set up the Storage Account as origin for Front Door. Fill in auto-generated URL of Static website into fields Host name and Origin host header.

Select Enable private link service and select your Storage Account resource. Select a sub resource web. Be sure, that values of Host name and Origin host headers didn’t changed to different one, overwrite them if that happened.

Configuration above is derived from Private Link architecture – it will register in internal DNS zone different record (something close to private IP) for your resource – when Front Door try to access this host name, private IP record is used and it’s not routed via public internet.

Approve a Private Link request

When you submit form from previous section, a request for new Private Link connection has been created.

Go to Private Link Center (you can find it by typing “Private Link” into Search resources field) and approve the request in Pending connections.

The Result

Thanks to settings above, I am able to access the website via Front Door only:

When I try to bypass Front Door and access Storage Account directly, I receive an error: