Two different questions
- May this user perform this action? Django's permissions answer this
- May this user access this record? This needs building
The most common authorisation failure in business applications is checking the action but not the record. A user permitted to view orders viewing someone else's order.
Filter at the query
- Every list query filtered by what the user may see
- Every detail view checking ownership before rendering
- Never trusting an identifier in the URL to determine access
- The same rules applied to any API endpoints
- The same rules applied to exports and reports
Exports are the commonly forgotten one. A report that ignores the permission filter leaks everything the interface carefully restricted.
Multi-tenant separation
| Approach | Suits |
|---|---|
| Tenant field on every model, filtered | Most business applications |
| Separate schema per tenant | Stronger separation, more operational work |
| Separate database per tenant | Strongest, most operational work |
For most applications, a tenant field with enforced filtering is adequate — provided the filtering is genuinely enforced everywhere rather than remembered on each query.
Enforce it centrally
Relying on every developer to remember the filter on every query is how leaks happen. Enforce it in a base manager or a mixin so the safe path is the default.
Then any query that bypasses it is visible in review as an explicit exception rather than an omission.
Test it adversarially
- Two accounts, deliberately trying to reach each other's records
- Direct URL access with another user's identifiers
- Exports and reports, not just screens
- API endpoints, not just the web interface
- After every significant change