Best practices · Security
Authorization Best Practices
Opens with creditsA practical guide to authorization for developers who build apps where users should only see and change some of the data. It covers deny by default and server-side checks, object-level authorization against IDOR and BOLA, choosing between RBAC, ABAC and ReBAC, multi-tenant isolation with row-level security, policy engines, admin and support access, auditing, and testing that permissions actually hold.
Written by Tauseef Fayyaz7 chapters, 22 practicesAbout 22 min23 quiz questionsReviewed 13 October 2026What you will learn
7 chapters · about 22 min
1Deny by default, check on the serverThe three rules every other practice builds on: nothing is allowed unless a rule says so, the check runs on the server for every request, and an error means no.3 practices · 3 min
2Object-level authorization: stop IDOR and BOLAChecking that a user may call an endpoint is not enough. Each object they ask for, by ID, has to belong to something they may access.4 practices · 4 min
- Choosing a model: RBAC, ABAC and ReBACRoles, attributes and relationships each answer "may this user do this?" differently. Pick the one that matches how your product actually shares data.3 practices · 3 minOpens with credits
- Multi-tenant isolationIn a SaaS app, the worst authorization bug is one tenant seeing another tenant's data. Isolation has to hold in the database, the cache and every background job.3 practices · 3 minOpens with credits
- Policy engines, tokens and servicesAs an app grows, authorization logic moves out of controllers into one decision point. These practices keep that decision correct across services and tokens.3 practices · 3 minOpens with credits
- Admin access, support access and auditingAdmins and support staff can see the most data, so their access needs the most care: separate controls, time limits and a record of what they did.3 practices · 3 minOpens with credits
- Testing authorizationPermissions break silently: nothing crashes, the wrong person just sees the data. Automated tests are how you notice before they do.3 practices · 3 minOpens with credits
About this guide
Authorization decides what a signed-in user is allowed to do. Authentication tells you who sent a request; authorization decides whether that person may read this invoice, edit this project or open the admin page. It is also where web apps fail most often. Broken Access Control has been number one on the OWASP Top 10 since 2021, and the 2025 edition says every application in its data set had some form of it, with 40 weaknesses mapped to the category, including server-side request forgery.
The bugs are rarely exotic. An API returns any order whose ID you put in the URL. A "hidden" admin button is hidden, but the endpoint behind it is not checked. A tenant ID comes from a request header and is trusted. A permission check exists in the controller for the web app, but not in the one the mobile app calls. Each one is a missing line of code, and each one leaks data at scale because IDs are easy to enumerate.
This guide covers authorization best practices from the ground up. It starts with the principles (deny by default, check every request on the server, fail closed), then object-level authorization, then how to choose between role-based, attribute-based and relationship-based access control. It moves on to multi-tenant isolation with PostgreSQL row-level security, policy engines and service-to-service calls, admin and support access with auditing, and finally how to test authorization so it stays correct. The advice follows the OWASP Authorization and IDOR Prevention cheat sheets, the Multi-Tenant Security cheat sheet, the ASVS 5.0 authorization chapter (V8), NIST SP 800-162 on ABAC and the PostgreSQL documentation.
Common questions
What is the difference between authentication and authorization?
Authentication establishes who is making a request, for example by checking a password or passkey. Authorization decides what that identity is allowed to do, such as reading a specific invoice or opening the admin area. Both are needed, and authorization has to run on every request.
What is IDOR or BOLA?
An insecure direct object reference (IDOR), called broken object level authorization (BOLA) in API security, is when an app returns or changes an object just because the caller supplied its ID. The fix is to check on every request that the object belongs to something the caller may access, ideally by scoping the database query to the user or tenant from the session.
Should I use RBAC, ABAC or ReBAC?
Most apps combine them: a few roles for broad functions, relationships for sharing objects, and attributes for conditions like plan or state. OWASP's Authorization Cheat Sheet says ABAC and ReBAC should typically be preferred for application development, while RBAC is simpler to start with but struggles with per-object rules and many tenants.
Are UUIDs enough to prevent IDOR?
No. Random IDs make guessing harder, but they leak through links, logs and screenshots. OWASP says access control checks are essential even with complex identifiers. Use random IDs as defense in depth and keep the ownership check.
How does row-level security help multi-tenant apps?
PostgreSQL row-level security applies a policy to every query on a table, so rows from other tenants are filtered out even if application code forgets a WHERE clause. Enable and force it on tenant tables, connect as a role without superuser or BYPASSRLS, and set the tenant value per transaction.
Should a forbidden object return 403 or 404?
When the caller should not even know the object exists, return 404, the same as for an ID that does not exist, so responses do not reveal which IDs are real. Use 403 when the caller can already see the object but may not perform the specific action.
Sources (8)
Checked against these, last on 13 October 2026.
- Authorization Cheat Sheet, OWASP Cheat Sheet Seriescheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
- Insecure Direct Object Reference Prevention Cheat Sheet, OWASP Cheat Sheet Seriescheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html
- Multi-Tenant Application Security Cheat Sheet, OWASP Cheat Sheet Seriescheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html
- A01:2025 Broken Access Control, OWASPtop10.owasp.org/2025/A01_2025-Broken_Access_Control
- API1:2023 Broken Object Level Authorization, OWASP API Security Projectapi-security.owasp.org/editions/2023/en/0xa1-broken-object-level-authorization
- ASVS 5.0 V8 Authorization, OWASPgithub.com/OWASP/ASVS/blob/master/5.0/en/0x17-V8-Authorization.md
- Row Security Policies, PostgreSQL documentationwww.postgresql.org/docs/current/ddl-rowsecurity.html
- NIST SP 800-162: Guide to Attribute Based Access Control (ABAC) Definition and Considerations, NISTcsrc.nist.gov/pubs/sp/800/162/upd2/final
Related on Sefism
Picked from the other libraries by shared topics.
Roadmaps
See allCheat sheets
See allBest practices
See all- Authentication Best PracticesBuild sign-in that holds up: password rules from NIST, Argon2id hashing, login throttling, MFA and passkeys, secure sessions and safe account recovery.
- Secure Coding Best PracticesWrite code that resists attack: untrusted input, validation, parameterized queries, output encoding, safe parsing, uploads, SSRF and errors that fail closed.
- Browser Security Best PracticesSecure the front end and HTTP layer: XSS and Trusted Types, Content Security Policy, CORS, cookies, CSRF, framing, security headers, third-party scripts and postMessage.
Checklists
See all- Web Application Security ChecklistA practical web application security checklist built on the OWASP Top 10:2025 and ASVS 5.0, with a severity and a way to verify every check.
- API Security ChecklistCheck your REST or GraphQL API against the OWASP API Security Top 10: authentication, object authorization, rate limits, input validation, SSRF, CORS and logging.
- Linux Server Hardening ChecklistHarden an Ubuntu, Debian or RHEL server step by step: accounts and sudo, SSH, updates, firewall and open ports, permissions, logging and CIS benchmark scans.
Project structures
See all- Firebase (Cloud Functions and security rules) project structureFor students building an app on Firebase who need a real backend: Cloud Functions (2nd gen) in TypeScript, Firestore and Storage security rules with tests, and the Local Emulator Suite. The tree starts from
firebase initand grows into feature folders of callables, triggers and scheduled jobs, then adds CI deploys, environments, contract tests and runbooks. - AI agent with an MCP server project structureFor developers who want to give AI assistants safe access to their own data or API. A TypeScript MCP server built on the official SDK, organised by feature (tasks, projects) with each feature owning its tools, resources and prompts, served over stdio for local hosts and Streamable HTTP with OAuth for remote ones, plus a small agent and the evals that prove a model can use it.
- Terraform project structureAn infrastructure repository for a small app on AWS: reusable modules, one folder per environment with its own remote state, pinned providers, tests and security scans, with plan on every pull request and apply from CI. For students who have finished the Terraform tutorials and want to know how a real team lays out the files. The same layout works unchanged with OpenTofu.
Career questions
See all- How do I get into AI security as a student or junior engineer?Build a normal security or software foundation first, then learn how LLM apps fail using the OWASP Top 10 for LLM Applications and MITRE ATLAS, and prove it by building, testing and hardening a small LLM app of your own. Most people reach AI security through AppSec, security engineering or ML engineering, not straight from university.
- Where do I start if I want a career in cybersecurity or IT operations?Start with the foundations both fields share: networking, Linux, and how systems fail. Then choose an entry role such as SOC analyst, IT support or junior cloud operations, and prove it with hands-on labs and one documented project rather than a stack of certificates.
- Can I use AI coding tools at my internship, and what should I never paste into them?Usually yes, but only the tools your company has approved, on the code and data they allow, and in the way they allow. Ask in your first week. Never paste secrets, customer data or code you are not permitted to share, and review everything the tool writes as if your name is on it, because it is.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com