Join Log in
Score:0
BlackMiracle avatar Server

Blocking direct access to static website on Azure Blob Storage and allow only Azure Front Door

in flag
BlackMiracle

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.

425
1 + 0
Score:0
avatar Server
ng flag
Sam Cogan

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.

0 + 6
BlackMiracle avatar
in flag
BlackMiracle
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
0
Reply
ng flag
Sam Cogan
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.
0
Reply
in flag
Anthony Chu
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.
0
Reply
in flag
Anthony Chu
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.
0
Reply
BlackMiracle avatar
in flag
BlackMiracle
@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](https://azure.microsoft.com/en-us/updates/) page?
0
Reply
in flag
Anthony Chu
Yes we should have an Azure Update announcement on this, although it might say something like network restrictions and service tags or something like that. Also I want to make it clear that this is for Azure Static Web Apps, which is a separate product than the static website hosting feature in Azure Storage. I think it’s perfectly fine to stay on Storage and use an unguessable account name. It’s usually not a big security concern to do that. Mainly you want to prevent Google from indexing it and stuff like that.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.