[finding] `org_member` can read every sys_invitation row in the org — other people's emails, granted roles, inviter — intended?

[baozhoutao]

Recording an observation for the platform to rule on — I could not tell from the outside whether this is intended.

A user whose org role is member can read every invitation row of the organization through the data API, including invitations addressed to other people: their email address, the role they are being granted, and the inviter.

Repro (measured)

Org 甲 has two invitations: lisi@ (member, accepted) and wangwu@ (admin, pending). lisi@ is a plain member of that org.

As lisi@, with the active organization set to 甲:

await fetch('/api/v1/auth/organization/get-active-member') // → { role: "member" }
await fetch('/api/v1/data/sys_invitation')
// → 200, total: 2
// [ { email: "lisi@acme-test.com", role: "member", status: "accepted" },
// { email: "wangwu@acme-test.com", role: "admin", status: "pending" } ]

Identical to what the org owner sees. Full rows also carry inviter_id and expires_at.

For contrast, the same member is correctly denied elsewhere:

GET /api/v1/data/sys_permission_set
→ 403 [Security] Access denied: operation 'find' on object 'sys_permission_set'
 is not permitted for positions [org_member, everyone]

so object-level gating is in force generally — sys_invitation is simply readable by org_member.

Why it might matter

A pending invitation is administrative intent, not a colleague directory: it exposes the addresses of people who are not yet (and may never become) members, and discloses who is about to be made an admin. Membership (sys_member / the members page) is a different question — that one reads like a legitimate staff directory.

The decision

Either confirm org_member read on sys_invitation is intended (in which case this issue is just documentation), or narrow it — e.g. restrict to owner/admin, or row-scope it to email = current_user.email so a member can still see their own invitation.

Related UI-side finding: #8092 (the members page shows invite/remove affordances to member; the server does gate those writes).

Environment

Local dev server http://localhost:8080, multi-org enabled, observed 2026-08-12. The server was started by the maintainer and its exact commit is not verified.

[baozhoutao]

Bugs filed from the same multi-org walkthrough: #8090, #8091, #8092, #8093, #8094.

[hotlong]

Triage: escalated to needs-user-decision, routed domain:identity; the filer-applied domain:access-security label was removed per the standing rule (not a lane in the domain table — labels are re-routed to the lane of the package the fix would land in). This is a security/permission-boundary question — whether org_member should read the org's whole invitation ledger — and that class is always the maintainer's, whichever way it goes.

Producer located (the "who writes this" question, answered): the read is not an accident of a wildcard. packages/plugins/plugin-security/src/objects/default-permission-sets.ts → denyWritesOnManagedObjects() grants allowRead: true on every BETTER_AUTH_MANAGED_OBJECTS entry (incl. sys_invitation) for the default member/viewer sets — a deliberate "writes must flow through better-auth, reads permitted subject to RLS" baseline. The RLS chain then org-scopes but does not row-scope within the org. So declared = enforced; the question is whether the declaration is right for this object.

Four-lens block:

1. Platform long-term coherence — the blanket read baseline is coarse by design; carving per-object read exceptions erodes its simplicity, but sys_invitation is qualitatively different from a staff directory: it is administrative intent about non-members. A row-scope carve-out follows the existing sys_*_org policy pattern rather than inventing a mechanism.
2. Measured business pull — measured live by the filer: a plain member reads other people's email addresses, granted roles (including who is about to be made admin), inviter, expiry. Pending invitees are not members and never consented to a directory listing. Real exposure, today, on every multi-org deployment.
3. AI-agent error-resistance — narrow-by-default wins: an app author (or agent) building on the data API will silently inherit the wide read and ship it. A closed default (owner/admin + own-row) fails loudly and is correctable; the wide default fails silently.
4. Startup scope discipline — the narrow fix is one RLS row-scope policy + one permission tweak, not a new capability; "confirm as intended + document" is the only cheaper option and spends trust instead of code.

Recommendation: narrow — restrict sys_invitation read to owner/admin, plus a row-scope carve-out email == current_user.email so an invitee can still see their own invitation (the accept flow's need). If ruled intended instead, the ruling should say so on this card and the read stays documented as a product decision. Related UI half: #8092 (affordance gating; moving to objectui as its own card).

本评论来自分诊座位 Routine。

---

Generated by Claude Code