Static-web-apps: Preventing Access to Certain Files - eg) appsettings.json

[justinyoo]

I'm experimenting Blazor Web Assembly app with Azure Static Web Apps.

When I deploy the app, it uses appsettings.json for its configuration because apparently Blazor Web Assembly can't have access to the environment variables defined at the Configuration blade.

However, the problem is that I can see the appsettings.json file by manually entering it on a browser. For example, when I type https://captain-america-123456.azurestaticapps.net/appsettings.json, it shows the contents that may contain sensitive information, which should be avoided.

It is the related issue to #47. How can we avoid certain file from being accessible from public?

[annaji-msft]

Thank you @justinyoo for trying out Static Web Apps.

You could use routes.json and authentication techniques provided by the service to protect this sensitive file.

This is great feedback as we work towards enabling blazor web assembly officially. We will try provide better ways to deal with the appsettings.json and its contents @dariagrigoriu @danroth27

[danroth27]

@justinyoo Blazor WebAssembly apps are client-side apps that are downloaded by the browser and run on the client machine. To expose configuration data to the Blazor WebAssembly it it needs to be retrievable by the app. The appsettings.json file in a Blazor WebAssembly app is used for this purpose. The app retrieves this config file and reads it, which means that anyone else could do the same thing. Any configuration data exposed to the app should be considered as publicly available.

In general, Blazor WebAssembly apps cannot store or handle sensitive secrets on the client. Instead secrets need to be handled on the server. In an ASP.NET Core hosted Blazor WebAssembly app, the server has its own config file which is not accessible over the network.

I hope this helps!

[annaji-msft]

Thanks @danroth27 for chiming in.

@justinyoo The option you might have already explored is to store appSettings(secrets) on Functions and retrieve them on the client-side as needed. Understand these will still show up on the client in network traffic. To completely hide the values you would have to move the sensitive logic to functions or proxy calls via functions.

Hope it helps.

[justinyoo]

Thanks @anganti @danroth27 for clarifying that! I'll take more look at the routes.json whether it can prevent access to appsettings.json from the public or not.

[justinyoo]

Now I understand the routing mechanism. routes.json can't prevent access to physical files.

[miwebst]

This should be possible using the shared auth experience that we have today. What is your desired scenario?

[justinyoo]

@miwebst I'm deploying my Blazor Web Assembly app to Azure Static Web App (ASWA).

As of today, ASWA (preview) supports JavaScript-based static web apps, not web assembly-based ones. Therefore, to get my Blazor app working, I have to include both appsettings.json and routes.json to my app, which is not supposed to open to public access.

Based on this doc, I tried a few tweaks on routes.json like:

{
  "routes": [
    { // 1
      "route": "/appsettings.json",
      "allowedRoles": [ "authenticated" ]
    },
    { // 2
      "route": "/appsettings.json",
      "statusCode": 404
    },
    { // 3
      "route": "/appsettings.json",
      "statusCode": 301
    },
    { // 4
      "route": "/*",
      "serve": "/index.html",
      "statusCode": 200
    }
  ]
}

Of course, I added // 1 & // 4, //2 & 4, or // 3 & 4 at the same time, not the whole. But none of them worked. Actually, any physical file access doesn't apply this routes. As @danroth27 mentioned above, I don't think it's possible to prevent those physical files from public access.

[miwebst]

So you can prevent access to particular files with routing rules like this:
{ "route": "/appsettings.json", "serve": "/", "statusCode": 301 },

This will redirect anyone asking for this file back to the root of your application.

[justinyoo]

And it will have consequences. So be mindful of using the rouets.json that @miwebst suggests above!

I'll close this issue now.