OWASP-style scanners catch the obvious holes — SQL injection, XSS, weak headers. They do not catch the class of bugs that only matters when you have many tenants sharing one database, one queue, and one file system. This is the checklist I wish every Laravel SaaS team ran before going live.
Tenant scoping has to be impossible to forget
A global scope on every tenant-bound model is non-negotiable. Relying on developers to remember to filter by tenant_id on each query is how data leaks happen on a Friday afternoon.
Pair the global scope with a static analysis check or a test that fails when a query against a tenant model is run outside a tenant context. The compiler cannot help you here, so your test suite has to.
Queues, jobs, and the cross-tenant blast radius
Background jobs are where tenancy quietly breaks. A job is queued under tenant A, dispatched, and runs in a worker that has no idea who it belongs to. The fix is to serialise the tenant ID into the job and re-bootstrap the tenant context in the handle() method.
Never use a single shared queue connection for tenant-sensitive work without that re-bootstrap step. And never rely on the previous job to have cleaned up the global state — workers are long-lived, and stale tenant context is a real-world incident.
- Tenant ID embedded in every job constructor
- Re-resolve tenant context at the start of handle()
- Per-tenant rate limits on expensive jobs to stop a noisy neighbour starving the queue
- Failure handlers that log the tenant ID, not just the exception
Files, storage, and the path traversal you forgot about
Tenant-uploaded files belong under a path namespaced by tenant ID. Anything else opens the door to one tenant guessing another tenants storage path. Signed URLs with short expiry are the bare minimum for downloads.
Be paranoid about file types. A logo upload that accepts SVG is XSS waiting to happen. Strip on upload, never on display.
Operational hygiene that auditors never ask for
Disable config:cache on environments where install or onboarding middleware mutates config. It is the kind of footgun that only fires after a deploy on a quiet Sunday.
Keep an incident runbook in the repo, not in a wiki nobody updates. The day a session is hijacked, you want the rotation steps next to the code, not three Slack searches away.
Takeaway
OWASP gets you to "no obvious holes". Multi-tenant safety gets you to "one tenants mistake cannot become another tenants incident". Those are different goals, and shipping a SaaS responsibly means owning both.
