IMovieService example can lead to authorization problems

[davisnw]

Description

The page gives an example of creating a common interface IMovieService with two implementations: ClientMovieService and ServerMovieService.

Neither the page nor the linked github code example (BlazorWebAppCallWebApi) have any discussion of the ASP.NET Core endpoint authorization.

So, for example, since ClientMovieService goes through "web api", traditional authorization attributes such as [Authorize("MyPolicy")] could be applied to individual endpoints (so e.g. Updating a movie has different permissions than reading a movie), however, the same operation in SSR going through ServerMovieService implementation would not have any of those authorization attributes applied.

This bifurcation of authorization stacks seems like an area rife for security holes, so some discussion of handling authorization when providing multiple implementations of a service for client-side vs server-side rendering seems to be warranted.

To further add to some of the confusion, in the github sample (BlazorWebAppCallWebApi), there is a tremendous amount of duplication in the minimal api spec and the ServerMovieService:

git difftool dbca3f4:9.0/BlazorWebAppCallWebApi/BlazorApp/BlazorApp/Program.cs dbca3f4:9.0/BlazorWebAppCallWebApi/BlazorApp/BlazorApp/Services/ServerMovieService.cs

So now there are actually 3 separate implementations of the movie related functionality.

Page URL

https://learn.microsoft.com/en-us/aspnet/core/blazor/call-web-api?view=aspnetcore-9.0

Content source URL

https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/blazor/call-web-api.md

Document ID

c7e59a08-1c60-32c2-75fd-33cb77ff7a5d

Article author

@guardrex

Metadata

• ID: 8b5e2e10-ff7b-2b9f-84da-f16028ae2c53
• Service: aspnet-core
• Sub-service: blazor

Related Issues

[github-actions]

💃🕺🥳 Happy New Year! 🎈🎆🍾🥂🎉

Stand-by! ... A green dinosaur 🦖 will be along shortly to assist.

[guardrex]

Hello @davisnw ... Let me get back to you on this, hopefully tomorrow morning (Thursday).

[guardrex]

I'm back! Sorry for the delay.

Neither the page nor the linked github code example (BlazorWebAppCallWebApi) have any discussion of the ASP.NET Core endpoint authorization.

It's not covered here at the moment. Secure web APIs are covered by the main doc set articles, which apply to most Blazor scenarios (especially on the server-side), and the Blazor node Security and Identity articles.

I want to mention in passing that a goal for the Blazor sample apps was to include secure web API calls. Devs can follow the patterns for typical secure web API call scenarios. Here are the examples:

• Standalone Blazor WebAssembly with Identity: Includes two secure data processing endpoints, one of which has an auth policy applied. The article covers cross-domain/same-site concepts and antiforgery.
• BWA with Entra: Includes a secure weather forecast web API.
• BWA with OIDC: Includes a secure weather forecast API for both the non-BFF and BFF patterns.

I agree with you that this article and the sample apps for it should include basic security patterns. I'll schedule this issue for work, and I hope to reach it within the next couple of weeks.

Notes for updating the article and samples:

• Address your concern, namely that "some discussion of handling authorization when providing multiple implementations of a service for client-side vs server-side rendering seems to be warranted."
• "there is a tremendous amount of duplication in the minimal api spec and the ServerMovieService": Yes, I agree. I'll resolve this problem.
• Add basic web API security scenario coverage for typical apps into the text coverage.
• Add the scenarios described to the sample apps.
• Cross-link the examples in the existing Blazor samples.
• Cross-link the extended coverage in the Blazor Security and Identity node.
• Improve the organization of coverage.

On your last point, you wrote ...

So now there are actually 3 separate implementations of the movie related functionality.

I don't follow. There's the service for server-rendered components (SSR), and there are the endpoints for web API calls for CSR. The "Backend" app only manages Todo list examples. What's the third "implementation" that you're referring to for the movie examples?

[davisnw]

---

• Standalone Blazor WebAssembly with Identity: Includes two secure data processing endpoints, one of which has an auth policy applied. The article covers cross-domain/same-site concepts and antiforgery.

I don't see this as particularly relevant to this issue?

• Sample project: 9.0/BlazorWebAssemblyStandaloneWithIdentity/BlazorWasmAuth.sln
• Unless I am missing something, there is no pre-rendering or SSR
• Thus the authorized endpoints (/data-processing-1 and /data-processing-2) have a single implementation
• Authorization unambiguously happens at the endpoint level

---

• BWA with Entra: Includes a secure weather forecast web API.

I don't currently have an Entra instance readily available to run this example, however, from inspecting the code, the IWeatherForecaster example is another illustration of my concerns with what I view as problematic from a security perspective:

• Sample project: 9.0/BlazorWebAppEntra/BlazorWebAppEntra.sln
• When rendering in CSR, authorization is enforced by the /weather-forecast api (registered in BlazorWebAppEntra/Program.cs
• For SSR/pre-rendering authorization is enforced by BlazorWebAppEntra.Client/Pages/Weather.razor
• BlazorWebAppEntra/Weather/ServerWeatherForecaster.cs does not itself perform any authorization checks
• Thus you now have two different authorization stacks in place for the same fundamental data/action.
  • In this particular case the authorization requirements are the same
  • However, one can quite easily imagine a scenario where the specs say that the data from IWeatherForecaster should be restricted by MyPolicy, and the dev only adds it to the endpoint registration (or vice versa, only adds it to the razor componet), leading to an authorization hole where depending on whether the page is rendered entirely CSR or SSR/pre-rendered you have different policies applied, leading to unintended information disclosure. This is particularly problematic as it can easily escape immediate user-testing as you would have to ensure that you actually access the page both as pure CSR rendering and as SSR/pre-rendered
  • This problem only gets worse as an application becomes more complex. In the particular case illustrated by the sample, there is a one-to-one correspondence between data exposed by the /weather-forecast endpoint and the Weather.razor page. Such a one-to-one correlation between an api and a razor component is not going to always exist, leading to even more opportunity for unintended information disclosure when different data has different authorization requirements
  • A potential solution would be to consolidate authorization logic into the ServerWeatherForecaster.cs, but that would appear to negate any declarative usage of the ASP.NET Core authorization stack altogether and could cause other problems (e.g., how would you force [Authorize("mypolicy")] attributes to be checked if they decorated the ServerWeatherForecaster or IWeatherForecaster? How would that authorization flow through to http 401 or 403 responses for unauthorized users calling the web api?)

---

• BWA with OIDC: Includes a secure weather forecast API for both the non-BFF and BFF patterns.

Same comments on 9.0/BlazorWebAppEntra/BlazorWebAppEntra.sln apply to 9.0/BlazorWebAppOidc/BlazorWebAppOidc.sln

---

On your last point, you wrote ...

So now there are actually 3 separate implementations of the movie related functionality.

I don't follow. There's the service for server-rendered components (SSR), and there are the endpoints for web API calls for CSR. The "Backend" app only manages Todo list examples. What's the third "implementation" that you're referring to for the movie examples?

What I meant was:

• You have two implementations of IMovieService (ServerMovieService and ClientMovieService)
• The "third" implementation is the completely separate code for the movie minimal api endpoints

[guardrex]

Yes, working on standalone WASM web API security isn't the focus of your issue, but I'd like to work on it at the same time. I'm going to use your issue in a general way to address web API security in this article.

On your second point, I understand, but this is what the product unit has advised developers to do (at least so far 😄). To discuss or pitch alternatives, you would need to open an issue on their repo. We only work on docs here. They work on the framework from the dotnet/aspnetcore repo. Open an issue here ...

https://github.com/dotnet/aspnetcore/issues

Please add ...

cc: @guardrex https://github.com/dotnet/AspNetCore.Docs/issues/34586

... to the bottom of your opening comment so that I can follow along.

I'd like leave your issue open here for work, so don't close this.

On the third point ... the "third" implementation ... I understand you're referring to the endpoint security "implementation" paradigm. However, that discussion would need to go to the product unit engineers. This is the strategy that they currently recommend. If you open an issue, I'll definitely follow the discussion that you have with them, looking for ways to improve the guidance.