Security: $expand bypasses RLS/FLS on the referenced object (data leak on lookups)

[os-zhuang]

Found by the ADR-0090 D10 adversarial security review. Pre-existing, general (affects all callers, not agent-specific).

What

expandRelatedRecords (packages/objectql/src/engine.ts:~1890-1896) resolves the referenced object by calling the driver directly, not this.find():

const expandOpts = this.buildDriverOptions(execCtx);
const relatedRecords = await driver.find(referenceObject, relatedQuery, expandOpts) ?? [];

It never re-enters executeWithMiddleware, so the referenced object's RLS, FLS, and CRUD gate are NOT applied — only tenantId is threaded (buildDriverOptions), so cross-tenant is still blocked. The middleware's post-pass FLS masking (security-plugin.ts ~1023) masks only the top-level object; field-masker does not recurse into expanded/nested records.

Impact

A caller who can legitimately read a base row can ?expand=<fk> and receive the full referenced record — including rows the referenced object's owner-only RLS would hide and fields FLS would mask — for any FK on a row it can see. Tenant isolation is the only surviving boundary.

Reachable via the REST data API: GET /data/:object/:id?expand=… and POST /data/:object/query forward expand (http-dispatcher.ts:~1953). (The MCP query/get tools do not forward expand, so the pure-agent surface is not exposed — but any API-key/session user is.)

Fix direction

Route $expand resolution through the security middleware for the referenced object (RLS + FLS applied per referenced object), or apply the referenced object's read filter + field mask to the expanded batch before attaching. Preserve the batched $in performance (don't N+1).

Refs

• packages/objectql/src/engine.ts:~1821-1903 (expandRelatedRecords)
• packages/runtime/src/http-dispatcher.ts:~1953-1958 (REST expand forwarding)

[os-zhuang]

Analysis + recommended approach (not yet implemented)

The $expand leak is really two issues with very different risk/value profiles — they should not be fixed with a single blanket flip.

① Field leak (FLS). You can see the related record, but you should NOT see fields the referenced object's FLS masks (account revenue, a user's national ID). There is essentially no legitimate case for a masked field leaking through a join — this is unambiguously a bug. Fixing it is low risk: it removes specific sensitive columns, never whole records, so it won't blank out "task shows its assignee"-style expands.

② Row visibility (RLS). "You may only expand records you could directly query." This is a genuine product decision with two defensible philosophies:

• Strict: expand must respect the referenced object's RLS (Salesforce, most DBs).
• Parent-authorizes: if you can see the parent, you can see its immediate FK targets (assignee/account) even if you couldn't query them directly — a denormalized-view convenience.

Today's behavior is accidentally parent-authorizes (it skips security). Flipping it blanket-strict would break a lot of "see parent → show related name/avatar" UX.

Key observation: the row-leak risk is concentrated on private referenced objects

• Referenced object is public (status, category, in-org user) → expand was visible to everyone anyway → applying RLS = zero change, zero risk.
• Referenced object is private/restricted → this is where rows actually leak. This is what to close.

Recommended approach — surgical, not blanket

One PR doing two things:

1. FLS masking always (both public and private referenced objects) — closes the field leak, near-zero blast radius.
2. RLS filtering only for private/restricted referenced objects — closes the real row leak while leaving the common public-lookup expand (status/category/owner) byte-identical (no blast radius).

Mechanism: private referenced objects resolve via the middleware-wrapped this.find (applies RLS+FLS); public ones keep the fast driver.find; FLS runs regardless.

Why not blanket this.find for every expand: even though it's a no-op for public objects' RLS, it also imposes the object-level CRUD gate + requiredPermissions on expansion — likely surfacing a cascade of "never designed for expand" modeling gaps (cf. the setup.write orphan capability found in #2848). The surgical version removes that risk surface.

Why not FLS-only: it leaves the private-row leak (you can still read a private account you can't query, via the join). That's a real hole, not just a field one.

Open design question before implementing

Are there places where parent-authorizes is a deliberate design choice (e.g. a detail page must show the assignee even if the viewer can't directly query that user)? If so, those relationships may need a per-field escape hatch (an explicit "expand is parent-authorized" marker) so the RLS-for-private rule doesn't break legitimate UX.

Found by the ADR-0090 D10 adversarial security review. Deferred pending the design decision above.