Should multi-tenancy be enforced in backend even if tenant is resolved on frontend (Next.js + Laravel API)?
06:57 06 Jan 2026

I am building a SaaS platform where each registered seller gets a subdomain like:

foo.example.com

Backend is Laravel 12 and frontend is Next.js, connected via REST API.

Each subdomain represents a shop with its own products, reviews, orders, etc.

However:

  • Users (customers) are not isolated per tenant
  • A customer can buy from multiple shops in one checkout
  • Only the seller-side data (products, shop settings, reviews, etc.) are tenant-specific

Current Implementation

In the frontend, I resolve the tenant from the subdomain and pass it to the backend: X-Tenant-ID: foo Then backend queries are filtered based on this tenant ID.

My Question

Is it safe and architecturally correct to:

Resolve the tenant only on the frontend, and trust the passed tenant ID

OR

Should the backend also enforce tenant resolution based on the request host (subdomain), even if frontend already sends tenant ID?

What I am specifically concerned about

  • Security risks of trusting frontend tenant ID
  • Correct architectural pattern for partial-isolation multi-tenant systems
  • How big SaaS platforms usually implement this when customers are shared across tenants

Example scenario

A malicious user modifies the API request and changes: X-Tenant-ID: foo → X-Tenant-ID: bar and gains access to another shop's data.

I would appreciate answers that cover:

  • Recommended backend enforcement strategy
  • Whether tenant context should be derived from Host header in backend
  • How to deal with shared users but isolated shop data correctly
laravel security architecture multi-tenant saas