Blazor Server事件与参数安全：是否需额外校验数据库查询？

背景依据 #

Events provide an entry point to a Blazor Server app. The same rules for safeguarding endpoints in web apps apply to event handling in Blazor Server apps. A malicious client can send any data it wishes to send as the payload for an event
——微软《ASP.NET Core Blazor Server威胁缓解指南》“Events”章节

基于已配置ASP.NET Core Identity、所有页面通过@attribute [Authorize]或<AuthorizeView>完成认证授权的Blazor Server（非WebAssembly）场景，针对以下案例明确核心问题：

案例1：带参数的Blazor组件 #

组件接收父页面传递的参数，加载时据此查询数据库：

[Parameter] public Guid companyGuid { get; set; }

protected override async Task OnInitializedAsync()
{
    using var context = DataService.CreateDbContext();
    var company = await DataService.GetCompanyByGuid(companyGuid, context);
}

案例2：基于权限预填充的下拉框 #

下拉框数据源根据用户权限预生成，选中值变更时触发数据库查询：

<RadzenDropDown Data=@DataSourceCompanies TValue="Company" 
@bind-Value="@selectedCompany"
Change="@(args => CompanySelectionChanged(args as Company))" />

List<Company> DataSourceCompanies = await GetCompaniesAndObserveUserPermissions(userGuid);

async void CompanySelectionChanged(Company c)
{
    using var context = DataService.CreateDbContext();
    var company = await DataService.GetCompanyByGuid(c.guid, context);
}

核心问题 #

1. 用户是否可通过非预期方式篡改案例1中的[Parameter]或案例2中的下拉选中项？
2. 是否必须为数据库查询方法GetCompanyByGuid添加用户ID校验（如下所示），即便全量改造涉及大量代码？

var authState = await authenticationStateTask;
string? userId = authState.User.FindFirst(c => c.Type.Contains("nameidentifier"))?.Value;
var company = await DataService.GetCompanyByGuid(c.guid, userId, context);

注：已查看微软文档但仍存疑，通过浏览器调试未发现可篡改的内部数据，但对SignalR机制不熟悉，担心存在滥用风险。

问题解答 #

问题1：用户能否篡改参数或下拉选中项？ #

能。Blazor Server通过SignalR与客户端通信，客户端发送的所有事件 payload 都是可篡改的：

• 对于案例1的[Parameter]：组件参数在初始化时由SignalR传输，恶意用户可通过伪造SignalR消息，修改companyGuid的值，传递任意Guid到服务端。
• 对于案例2的下拉选中项：下拉框的UI限制只是前端层面的，恶意用户完全可以绕过前端逻辑，直接发送包含未授权Company对象（或任意Guid）的SignalR消息触发CompanySelectionChanged方法，而非只能选择预填充的选项。

浏览器调试看不到篡改路径不代表没有风险——客户端可以通过拦截、修改SignalR的通信内容，或者直接构造符合格式的SignalR请求，向服务端发送任意数据。

问题2：是否必须添加用户ID校验？ #

必须。原因如下：

1. 认证（[Authorize]）仅验证用户身份合法，但不验证用户对特定资源（如某家公司数据）的访问权限。
2. 前端的权限控制（如案例2中预填充下拉框）仅作为用户体验优化，不能作为安全边界——恶意用户可绕过前端直接请求未授权数据。
3. 数据库查询必须遵循最小权限原则和权限校验下沉：将用户ID与资源ID的关联校验嵌入到数据访问层（如GetCompanyByGuid方法），确保无论请求来自何处，只有拥有访问权限的用户才能获取对应数据。

即使改造工作量大，这也是保障数据安全的必要措施——否则存在用户越权访问其他公司数据的风险，违反微软威胁缓解指南中“保护端点与事件处理”的核心规则。

内容的提问来源于stack exchange，提问作者Robert R