DEV Community: Auth By Example

A report that joins tables can leak rows your list pages would hide

Auth By Example — Fri, 09 Oct 2026 05:41:05 +0000

List endpoints usually filter by tenant and role. Reports often skip that. Someone builds a revenue report that joins orders to customers and territories, then runs a raw SQL query or an ORM join with no per-table access filter.

A sales rep who can only see their own territory still gets totals that include every order the join touches. Sometimes the detail rows are filtered and the summary cards are not, so the number on the dashboard is bigger than anything they can open.

Apply the same access filter each list endpoint uses to every table in the join, before you aggregate. If the rep cannot read an order, it should not count toward their report either.

Quick test: seed two territories, give a user access to only one, and run the report. The totals and the row count should match what their order list returns for the same filters.

What EU AI Act Article 12 and ISO 42001 mean for AI agent logs

Auth By Example — Thu, 08 Oct 2026 08:23:42 +0000

Article 12 of the EU AI Act says high-risk AI systems must technically allow automatic recording of events (logs) over the lifetime of the system. It covers high-risk systems only. An internal assistant that searches docs over MCP doesn't become high-risk because it uses MCP. Per artificialintelligenceact.eu, the obligations apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. Check the current consolidated text on EUR-Lex for your own case; none of this is legal advice.

ISO/IEC 42001 is broader and vaguer. Control A.6.2.8 asks you to decide in which life-cycle phases event logging is enabled, and "while the AI system is in use" is the minimum.

For agents I'd put that logging at the tool call. The model only suggests things, and the tool call is where data actually changes. Before each call with side effects, record:

who or what asked, and on whose behalf the agent acted
the tool, the action, and the resource it touches
the decision (allow, deny, or allow with approval) and the policy version behind it
who approved it, if a human had to sign off
what happened after the decision

Join those with one request ID. Log redacted parameters or hashes instead of raw prompts, so you can replay the decision later without hoarding data.

Disclosure: I work at Permit.io. We wrote up the Article 12 and ISO 42001 details, with a full field table for MCP tool calls:

https://www.permit.io/blog/eu-ai-act-article-12-iso-42001-agent-logging?utm_source=devto&utm_medium=social&utm_campaign=eu-ai-act-article-12-iso-42001-agent-logging&utm_content=authbyexample-article

GraphQL resolvers often check the top-level object and skip the nested ones

Auth By Example — Thu, 08 Oct 2026 06:09:13 +0000

A common GraphQL setup puts the permission check in the root resolver. project(id: 7) checks that you're a member of project 7 and returns it. Every nested field resolves on its own after that.

So a query like project(id: 7) { linkedProjects { name members { email } } } can walk right out of the project you were allowed to see. A linked project might belong to another team, and its members resolver never asked whether you can see that team.

What fixes most of it:

Put the check in each type's resolver, or in the data loader that fetches that type, keyed on the object being returned.
Treat any field that returns another object as a new authorization question, even when the parent passed.

To test it, sign in as a user who belongs to one project and write a query that follows every relation two or three levels deep. Any object from outside their projects that comes back is a hole. Introspection gives you the full list of relations to try.

The user picker in your share dialog can leak your whole user table

Auth By Example — Wed, 07 Oct 2026 14:18:57 +0000

Most apps have a little search box for picking people when you share a doc or assign a ticket. Behind it there's an endpoint like GET /users?q=ali that returns names and emails as you type.

That endpoint tends to get written quickly and reviewed last. Often the only check is whether the caller is logged in. So any signed-in user can type one letter at a time and walk your whole user table, across every tenant, emails included.

A few checks that close it:

Scope the query to the people the caller is allowed to see. In a multi-tenant app that means the caller's organization, and sometimes only members of the same workspace or project.
Check the action too. If the picker is for sharing document 42, confirm the caller can share document 42 before returning anyone.
Return only what the picker needs. A display name and an avatar are usually enough. Leave email out unless the caller already has a reason to see it.
Set a minimum query length and a rate limit, so nobody can page through the list with q=a, q=b, q=c.

Quick test: log in as a user in tenant A and search for a name you know exists only in tenant B. If it shows up, the picker is leaking.

An admin shouldn't be able to grant a role bigger than their own

Auth By Example — Wed, 07 Oct 2026 12:11:06 +0000

Most role-assignment endpoints check one thing: can the caller manage members? If yes, whatever role is in the request body goes through.

So a project admin sends PATCH /members/42 {"role": "owner"} with their own user ID, or a friend's, and now they hold permissions nobody gave them. The UI dropdown hid "owner". The API never did.

Two checks cover most of it:

The caller can only assign roles whose permissions are a subset of their own on that same resource.
The caller can't raise their own role. Someone with a higher role has to do that.

To test it, sign in with the lowest role that can manage members and call the endpoint directly with every role name your system has, including the ones that never show up in the dropdown. Anything above the caller's own level should come back 403.

If you want a refresher on how roles and permissions fit together, Permit.io has a short write-up (we're affiliated): What is RBAC?

Archiving a workspace should make the API read-only too

Auth By Example — Wed, 07 Oct 2026 10:39:44 +0000

Archiving usually ships as a UI change. The workspace moves to an "Archived" tab, the edit buttons go grey, and everyone moves on.

The API often never hears about it. A script with an old token, a webhook handler, or a teammate with a bookmarked form can still create tasks, rename files, or invite people into a workspace that's supposed to be frozen. Billing tends to break the same way: a customer downgrades or stops paying, the screens lock, and writes keep landing.

What helps:

Put the workspace state into the permission check itself. "Can this user edit tasks here?" should come back no when the workspace is archived, whatever role they hold.
Keep reads working. People archive things so they can still look them up later.
Decide what unarchiving needs. Usually that's an admin or owner action, and it should be checked and logged like any other role change.
Cover background jobs. Imports, syncs, and scheduled automations that write into the workspace should check the same state before they run.

Quick test: archive a workspace, then send a create or update request straight to the API with a token that was valid before. You want a 403 with a clear reason. A 200 means the archive only exists in the UI.

Four questions to ask about one real authorization flow

Auth By Example — Tue, 06 Oct 2026 13:31:32 +0000

A lot of authorization trouble has nothing to do with missing roles. The check exists somewhere, just not at the action that matters, or it runs on data that went stale an hour ago.

Try this on one flow that can actually hurt you, like inviting a user, exporting a report, or an agent calling a tool.

Does the action itself ask for a decision? A role check at login or on the route won't cover the list query that forgets to filter by tenant.
Does the decision know enough? user.role == "admin" ignores tenant scope, ownership and resource state. You want something closer to "can subject U do action A on resource R in tenant T right now?"
How long does a revoke take? If a removed user keeps export access until a 30-minute cache expires, decide whether that's fine for that action. For a UI hint, maybe. For a data export, probably not.
Can you explain the result later? A log line that says 403 won't tell anyone which policy decided or why.

Disclosure: I work at Permit.io. We wrote up these four areas (enforcement, granularity, realtime, audit) and the architecture that connects them:

https://www.permit.io/blog/enforcement-granularity-realtime-audit?utm_source=devto&utm_medium=social&utm_campaign=enforcement-granularity-realtime-audit&utm_content=authbyexample-article

Duplicating a record should check access to everything it copies

Auth By Example — Tue, 06 Oct 2026 08:36:57 +0000

"Duplicate project" is a handy button. The handler usually checks that the caller can read the project, then copies the project row and everything hanging off it: tasks, attachments, linked documents, saved filters.

The children don't always share the parent's permissions, though. A private task inside a shared project, or a document linked in from another workspace, gets copied into a new project the caller owns. Now they can read it.

What I'd do:

Run the read check on each child you copy, with the caller as the user. Leave out the ones that fail and tell the caller some items were skipped.
Copy references to other workspaces as links, so opening them still goes through the normal check.
Templates and "save as template" usually share this code path. Check them too.
Add a test: user A duplicates a project that contains a task only user B can see. The copy should not contain that task.

If you want every route to call one shared decision function, this write-up on splitting enforcement from the decision (PEP/PDP) covers the pattern. Disclosure: I work with Permit.io.

Attachment downloads should check the record they belong to

Auth By Example — Tue, 06 Oct 2026 06:44:40 +0000

Your GET /tickets/:id handler checks that the caller can see the ticket. The files attached to that ticket come from GET /files/:fileId, and that route only checks that someone is logged in.

So anyone holding a file ID can download a screenshot from another customer's support ticket. File IDs end up in notification emails and server logs, and they keep working after a user loses access to the ticket.

What I'd do:

Store the parent on the file row (parent_type, parent_id). The download route loads the parent and runs the same check the parent's own endpoint runs.
If you hand out signed storage URLs, sign them only after that check passes and keep the expiry short, a few minutes is plenty.
Thumbnails, previews and "download all as zip" usually have their own routes. Give them the same check, they are the ones that get missed.
Add a test where user A uploads to a ticket and user B from another tenant requests the file ID directly. B should get a 404.

Counts and totals need the same authorization filter as the list

Auth By Example — Tue, 06 Oct 2026 05:43:22 +0000

You locked down GET /invoices so it only returns rows the caller can see. Then the dashboard says "Invoices this month: 4,812", and that number comes from SELECT count(*) FROM invoices with no tenant filter.

Counts leak. So do sums, search facets like "Overdue (37)", and the "20 of 3,104" line under a paginated table. When those run on their own query path they can tell a user how large another tenant's account is, or whether a given customer exists at all, without returning a single row.

What I'd do:

Build the authorization filter in one place and pass it to the list query, the count query and every aggregate.
Check search facets and pagination totals separately. They often come from a different index call than the hits.
Add a test: a user who can see 3 invoices gets 3 from the count endpoint, and the facet numbers add up to 3.
If dashboard numbers are cached, put the tenant (or the user, when access is per user) in the cache key.

A valid token is not an AI agent audit trail

Auth By Example — Mon, 05 Oct 2026 08:15:34 +0000

When an AI agent issues a refund or edits a record, your IdP log says a token existed and your app log says an endpoint was hit. Neither tells a reviewer why the action was allowed.

The record that does is written at decision time, and it needs a few things most stacks don't capture today:

Delegation: which agent acted, and on behalf of which human or workflow
Tool and parameters: what was actually requested, not just which API was called
Policy ID and version: the rule set that was evaluated at that moment
Decision plus reason: allow or deny, with something a person can read
Approval record: who approved a human-in-the-loop step, and when
Outcome: whether the side effect really happened

Join them with a trace ID and a tenant, and you can rebuild an agent's action months later without guessing.

Disclosure: I work at Permit.io. We wrote up the full twelve-field list, with an example record and what to leave out for read-only assistants:

https://www.permit.io/blog/ai-agent-audit-logs-12-fields?utm_source=devto&utm_medium=social&utm_campaign=ai-agent-audit-logs-12-fields&utm_content=authbyexample-article

An email domain is not tenant membership

Auth By Example — Mon, 05 Oct 2026 07:43:12 +0000

A common shortcut in B2B apps: "if the user's email ends in @acme.com, put them in the Acme workspace." It feels like authorization, because only Acme employees should have Acme addresses. But the domain only tells you who issued the mailbox, not who your customer has agreed to let in.

Things that break this assumption:

contractors, interns, and shared inboxes that use the company domain but shouldn't see everything
a former employee whose mailbox is still alive for a few weeks
subsidiaries or acquired companies that share a domain but are separate customers
public email providers, where "same domain" means nothing at all

A small example

# Risky: the domain decides membership
def on_signup(user):
    org = orgs.find_by_domain(user.email.split("@")[1])
    if org:
        memberships.add(user, org, role="member")

# Safer: the domain only suggests, the org decides
def on_signup(user):
    org = orgs.find_by_verified_domain(user.email.split("@")[1])
    if org and org.settings.auto_join_enabled:
        memberships.add(user, org, role=org.settings.default_join_role)
    elif org:
        join_requests.create(user, org)  # an org admin approves

The second version still uses the domain, but only as a hint. Membership comes from a decision the customer made: a verified domain, an explicit auto-join setting, and a default role they chose.

What helps

Verify domain ownership first (DNS TXT record or similar) before treating a domain as belonging to an org.
Make auto-join opt-in per org, and let admins pick the default role. "Member" in one company is "read-only guest" in another.
Keep checking membership, not the email. Every request should ask "is this user a member of this tenant with this role?", never "does their email match?"
Handle offboarding separately. SCIM or an admin removal should revoke membership even if the mailbox still exists.
Never auto-join on public domains like gmail.com or outlook.com.

The takeaway

The email domain is a useful signal for suggesting a workspace. It shouldn't be the thing that grants access to one. Let the tenant decide who's in, store that decision, and authorize against it.

How does your app handle domain-based auto-join today?