Row-level multi-tenancy in Laravel: the four leak modes

1. Eager loads that bypass global scopes

A `User` model with a `belongsToMany('orders')` relationship looks fine. But when you eager-load it — `User::with('orders')->get()` — Laravel calls Order's relationship loader directly, and depending on how you've registered the global scope, it can run without it. The query goes out without the `tenant_id` filter and returns every order in the database.

Two reliable fixes. First, register the global scope inside the `boot()` method on every tenant-bound model and verify it shows up in the relationship loader's query. Second, write a feature test that explicitly checks `User::with('orders')->toSql()` contains the tenant filter — once, then never have to think about it again.

// app/Models/Concerns/BelongsToTenant.php
trait BelongsToTenant
{
    protected static function bootBelongsToTenant(): void
    {
        static::addGlobalScope('tenant', function (Builder $q) {
            if ($id = app(TenantContext::class)->id()) {
                $q->where($q->getModel()->getTable() . '.tenant_id', $id);
            }
        });

        static::creating(fn ($m) => $m->tenant_id ??= app(TenantContext::class)->id());
    }
}

2. Queue jobs running without tenant context

The web request resolves the tenant from the subdomain, the route, or a JWT claim. Then the request ends. The job you dispatched runs ten seconds later in a worker that has no idea who the tenant was. If the job calls `Order::find($id)`, the global scope tries to read the tenant from a context that doesn't exist — and either fails closed (no results, silent breakage) or fails open (no scope, all tenants).

The fix is to pass tenant ID into every job constructor and bind it back into the container at the start of `handle()`. Or use a queue middleware that does this for any job tagged with a `TenantAware` interface. Don't rely on `Auth::user()` in queues — it's null.

class SendInvoiceEmail implements ShouldQueue, TenantAware
{
    public function __construct(
        public int $tenantId,
        public int $invoiceId,
    ) {}

    public function handle(): void
    {
        // TenantAwareMiddleware has already bound the tenant context.
        $invoice = Invoice::findOrFail($this->invoiceId);
        // ...
    }
}

3. Cache keys and Redis namespaces

`Cache::remember('user-roles', 300, fn () => …)` returns the roles for whichever tenant warmed the cache first. Every subsequent tenant reads the wrong data until the TTL expires. This is the single most common production multi-tenancy bug we see.

Either prefix every cache key with the tenant ID (a small wrapper around `Cache::store()` makes this automatic), or run a per-tenant cache store. The wrapper is cheaper. Redis namespacing via the `prefix` config option also works but only if the prefix is set per request, which means you can't share a connection pool naively.

4. Eloquent observers and side-effect handlers

An `OrderObserver::created()` that fires `Auth::user()->notify(...)` works fine when the order is created in a controller. It crashes when the order is created in a queued job, a console command, a webhook handler, or a broadcast event — anywhere `Auth::user()` is null.

Treat observers as if they always run with no auth context. Pass tenant explicitly through the model — `$order->tenant_id` is always there because of rule 1 — and resolve the responsible user (or a system user) from the model itself, never from the request.