Multi-Tenant Laravel SaaS: Data, Billing, and Permissions

The core promise of a Software-as-a-Service (SaaS) application is simple: multiple independent companies (tenants) use the exact same software, but their data remains completely separate. The administrative users of Company A must never, under any circumstances, see the invoices, customer records, or internal settings of Company B.

In B2B SaaS, a data leak is not just a bug; it is a business-killing event. If Company A discovers they can see Company B's reports by simply changing a URL parameter from /reports/5 to /reports/6, your trust is broken, your compliance is violated, and your reputation is ruined.

To prevent this, a professional Laravel SaaS application does not rely on developers manually adding filtering logic to every controller. Instead, we build a multi-layered security architecture that enforces tenant isolation automatically at the framework level. Here is the engineering blueprint for securing multi-tenant data, billing, and permissions in Laravel.

Defense Layer 1: Automatic Query Filtering (Global Eloquent Scopes)

The most dangerous point of failure in a shared-database SaaS is human error. If a developer joins the team and writes a query like Invoice::all() to display a list of billing records, and forgets to append where('tenant_id', auth()->user()->tenant_id), the application will display all invoices in the entire database to the logged-in user.

The Solution: We automate database filtering using Eloquent Global Scopes and PHP traits.

We create a trait called BelongsToTenant that is applied to every model containing tenant-owned data (e.g., invoices, tasks, projects). In migrations, these tables must have a foreign key column: $table->foreignId('tenant_id');.

Inside the boot method of the BelongsToTenant trait, we register a global scope:

static::addGlobalScope(new TenantScope);

The TenantScope class intercepts all Eloquent queries before they are sent to the database. It retrieves the logged-in user's tenant_id from the session or request header, and automatically appends a SQL filter: $builder->where('tenant_id', currentTenantId());.

Once this trait is added to a model, the query filtering is handled automatically. If a developer writes Invoice::all(), Laravel compile the SQL behind the scenes to: SELECT * FROM invoices WHERE tenant_id = 5. It is physically impossible to leak data, even if the developer writes a query without considering multi-tenancy.

Defense Layer 2: Scope Bypass and Shared Data Isolation

Not all data in a SaaS application belongs to a specific tenant. For example, a table of countries, currencies, or global system settings must be accessible to everyone. Conversely, system administrators running the platform need to view data across all tenants to run reports and resolve customer issues.

A secure isolation architecture must account for these edge cases without introducing security holes:

• Shared Tables: Models like Currency do not use the BelongsToTenant trait. They are stored in the shared database and queried globally without scopes.
• Administrative Access: System admins logging in to the central admin panel must be able to view all data. We use Laravel's withoutGlobalScope() method to temporarily disable the tenant filter, but only under strict administrative route groups guarded by specialized middleware: Invoice::withoutGlobalScope(TenantScope::class)->get();.

Defense Layer 3: Team-Level Billing Isolation

In a B2B SaaS, the subscription and payment status belong to the organizational tenant (the Company or Team), not to the individual users. A single company might have 50 employees using the platform, but only one credit card on file.

The Implementation: We attach our billing integration (Laravel Cashier) to the Team or Tenant model rather than the User model. The Tenant model holds the stripe_id and subscription columns. When an employee logs in, the application checks the subscription status of their parent team: if ($user->currentTeam->subscribed('premium')) { ... }.

If the team's credit card fails and Stripe moves their subscription status to 'past_due', the billing middleware intercepts any requests from all 50 employees of that team, redirecting them to a "billing payment required" screen. Individual users do not manage subscriptions; they inherit their authorization state from the tenant's commercial status.

Defense Layer 4: Role-Based Access Control Inside Tenant Boundaries

Even within a single tenant, not all users are equal. A junior support employee at Company A should not have the authority to invite new users, change the company's billing plan, or export the customer list. We must enforce permissions within the tenant context.

The Implementation: We use Laravel's Policy authorization system coupled with a role-based access control (RBAC) schema. We define policies for every sensitive resource. For example, before allowing a user to invite a new team member, the controller authorizes the request:

Gate::authorize('invite-member', $team);

Inside the authorization check, we verify:

1. The logged-in user belongs to the target team (Tenant Isolation).
2. The user's role on that team (e.g., 'Admin' or 'Owner') possesses the 'invite-users' permission (Resource Authorization).

If either check fails, Laravel throws a 403 Forbidden exception, stopping the request before any data is altered.

Zero-Trust Architecture

A secure multi-tenant platform is built on a zero-trust model. The database queries filter by tenant ID automatically, the billing middleware checks tenant statuses globally, and resource policies verify roles at every checkpoint. This defensive design ensures your customers' data remains safe, your compliance is maintained, and your product is built for scale.

If you are planning to build a multi-tenant SaaS application or need an architecture review of an existing system, visit my custom Laravel development services page to see how I help client teams implement secure multi-tenant systems.