DEV Community: Auth By Example

Separate who can grant from who can act

Auth By Example — Fri, 18 Sep 2026 18:29:12 +0000

In many apps, anyone with an “admin” role can both use privileged actions and hand those same powers to other people.

That mixes two different privileges:

Acting with a permission (delete a project, export data, approve a payment)
Granting that permission to someone else

If the same role covers both, a compromised admin account — or a confused admin — can quietly expand the blast radius. The attacker does not need to find every secret; they mint new admins.

A cleaner pattern is separation of duties:

Keep day-to-day privileged actions on an operator / admin role
Put permission grants, role assignments, and policy edits on a smaller grantor / IAM role
Require a second factor, approval, or short time box for grant actions
Audit grant events separately from ordinary use events

Authorization is not only “can this user do X right now?” It is also “who is allowed to change the answer to that question?”

Never trust a client-supplied tenant ID

Auth By Example — Fri, 18 Sep 2026 13:52:30 +0000

A common authorization bug: the API takes tenant_id from the request body or query string, then loads that tenant’s data if the user is authenticated.

Authentication only proves who you are. It does not prove which tenant you may act in.

Better pattern:

Resolve the caller’s allowed tenants from a server-side session, token claim you issued, or membership store.
Ignore or strictly validate any client-supplied tenant against that set.
Scope every query with the authorized tenant — never with the raw client value alone.

If the client can pick any tenant ID, they can often read or mutate another customer’s data. That is an IDOR wearing a multi-tenant costume.

Teach the check: “is this principal allowed for this tenant?” — not “does this tenant exist?”

Check permissions again after every trust boundary

Auth By Example — Fri, 18 Sep 2026 06:21:02 +0000

Authentication proves who someone is. Authorization decides what they can do. Those are different moments, and they do not travel together forever.

After a user crosses a trust boundary — a new service, a webhook handler, a background job, a different API gateway — re-check the permission for that action on that resource. A JWT that said "admin" at the edge is not a free pass deep inside your system.

Treat each hop as untrusted until your policy says otherwise. That habit catches broken assumptions when services are reused, messages are replayed, or callers change.

Default-deny beats allow-everything-then-trim

Auth By Example — Thu, 17 Sep 2026 14:56:25 +0000

Most apps start with a wide-open role and carve exceptions later. That creates silent privilege creep.

Prefer default-deny: every action is blocked until a grant says otherwise. New features stay locked until you deliberately open them. Audits get easier because you can list who was granted what, instead of hunting for forgotten carve-outs.

If a new endpoint needs access tomorrow, add an explicit permission. Don’t widen an existing role “just for now.”