1

I have an SPA webapp deployed on Azure Blob Storage which the URL is public. E.g. https://example.z23.web.core.windows.net/

I would like to use Azure Front Door with WAF to increase security. Is there a way to block direct access at the blob URL? I googled it and found many answers out there, one of them is to simply allow only AzureFrontDoor.Backend IPs at Storage Account networking configurations. I tried it and it worked.

However, this method still has a loophole as anyone can just create a Front Door and point to my blob URL (if they happen to discover it somehow).

(This might sound dumb): if I proceed with this method and name my storage account randomly, for example, use a trimmed-down random GUID. (https://6c4a89d5dba04b8fbe1ed7f.z23.web.core.windows.net/) Can this reduce the possibility that someone might discover my URL and bypass security?

Another method that Azure recommends is to check for X-Azure-FDID header that includes the ID of my particular Front Door instance and drop requests that don't contain this header. I asked my developer if this is possible on Vue webapp and he said we would need to include the Front Door ID in the code which runs on client-side thus exposing the ID to public anyway. (This is not Stack Overflow but if someone can suggest anything on this, it would be great)

Another way I found is to use Azure Front Door Premium SKU which supports connecting to Storage Account using Private Link. This is perfect, but it costs a whopping $165 per month. I'd rather deploy my code on App Service instead as it can natively restrict access from Front Door only.

Can anyone suggest any method on how to achieve this?

Thanks.

Improve this question

1 Answer 1

Reset to default
1

Checking the X-Azure-FDID header, in combination with the IP restriction is the only way to lock this down currently without going down the private link route. So you would need to get your application code to validate that, given you don't have anything else in-between FD and the storage account.

Whilst having this in your client side code would expose the ID, it doesn't really matter. The IP restrictions mean that your only allow traffic from Front Door instances, and there is no way for an attacker to set that ID on a different FD instance.

Improve this answer
6
  • Thanks for your reply. That sounds legit. You mentioned: "given you don't have anything else in-between FD and the storage account." Is there anything else I can add to achieve this without altering the code? Just curious
    – BlackMiracle
    Sep 1, 2021 at 15:34
  • not that doesn't add significant expense. You could look at application gateway rather than Front Door, but that's not cheap, you could also run your app on an app service or an AKS cluster and add additional services in front there, but again, adds more cost.
    – Sam Cogan
    Sep 1, 2021 at 15:38
  • I don’t believe you can access http request headers in client side JavaScript. I think naming your storage account with a difficult to guess name is your best bet.
    – Anthony Chu
    Sep 2, 2021 at 1:40
  • I’m not sure if Storage plans to add a similar functionality, but I’m on the Static Web Apps team and we are working on supporting this exact scenario, including the ability to lock down the app by service tags and to restrict access to a specific x-azure-fdid header. This should be available in the next month or two.
    – Anthony Chu
    Sep 2, 2021 at 1:45
  • @AnthonyChu Wow, it's a great news to hear from the product team that this feature is being worked on. Could you please share how customers would know when it's available? Can we check on Azure Update page?
    – BlackMiracle
    Sep 2, 2021 at 20:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .