IHttpContextAccessor/HttpContext in ASP.NET Core Blazor apps

IHttpContextAccessor generally should be avoided with interactive rendering because a valid HttpContext isn't always available.

IHttpContextAccessor can be used during static server-side rendering (static SSR), for example in statically-rendered root components, and when using a token handler for web API calls on the server. We recommend avoiding IHttpContextAccessor when static SSR or code running on the server can't be guaranteed.

HttpContext can be used as a cascading parameter only in statically-rendered root components or during static SSR for general tasks, such as inspecting and modifying headers or other properties in the App component (App.razor). The value is null during interactive rendering.

[CascadingParameter]
public HttpContext? HttpContext { get; set; }

For additional context in advanced edge cases†, see the discussion in the following articles:

• HttpContext is valid in Interactive Server Rendering Blazor page (dotnet/AspNetCore.Docs #34301)
• Security implications of using IHttpContextAccessor in Blazor Server (dotnet/aspnetcore #45699)

†Most developers building and maintaining Blazor apps don't need to delve into advanced concepts when the general guidance in this article is followed. The most important concept to keep in mind is that HttpContext is fundamentally a server-based, request-response feature that's only generally available on the server during static SSR and only created when a user's circuit is established.

Don't use IHttpContextAccessor/HttpContext directly or indirectly in the Razor components of server-side Blazor apps. Blazor apps run outside of the ASP.NET Core pipeline context. The HttpContext isn't guaranteed to be available within the IHttpContextAccessor, and HttpContext isn't guaranteed to hold the context that started the Blazor app.

The recommended approach for passing request state to the Blazor app is through root component parameters during the app's initial rendering. Alternatively, the app can copy the data into a scoped service in the root component's initialization lifecycle event for use across the app. For more information, see ASP.NET Core server-side and Blazor Web App additional security scenarios.

A critical aspect of server-side Blazor security is that the user attached to a given circuit might become updated at some point after the Blazor circuit is established but the IHttpContextAccessor isn't updated. For more information on addressing this situation with custom services, see ASP.NET Core server-side and Blazor Web App additional security scenarios.