Row-Level Security in Embedded Reporting: The Patterns That Actually Work for .NET SaaS
When you add embedded reporting to a multi-tenant SaaS product, row-level security isn't optional — it's the whole ballgame. One misconfigured RLS policy and you're serving Tenant A's data to Tenan...

Source: DEV Community
When you add embedded reporting to a multi-tenant SaaS product, row-level security isn't optional — it's the whole ballgame. One misconfigured RLS policy and you're serving Tenant A's data to Tenant B. In a B2B context, that's a trust violation that ends customer relationships. Here's a practical breakdown of RLS patterns for embedded reporting in ASP.NET Core, including the vulnerability that catches most teams. The Critical Rule Tenant ID must come from the server-side authenticated session. Always. This pattern is wrong: // DON'T DO THIS reportTool.init({ tenantId: document.getElementById('tenantId').value }); A malicious user changes that value. You have a cross-tenant data breach. This pattern is correct: // Server-side — user cannot tamper with this public override Task<DotNetReportUser> GetCurrentUser() { return Task.FromResult(new DotNetReportUser { ClientId = HttpContext.User.FindFirstValue("TenantId"), IsAdmin = User.IsInRole("ReportAdmin") }); } Two Layers of RLS Effec