Meteor Publish Functions as Server-Side Data Boundaries

Requirements for a secure publish design

Publish runs on the server and can read any document. The design must decide what crosses to the client.

• Data origin is server only. The publish function executes in Meteor.isServer context with direct database access.
• Trust boundary is explicit. The function must authorize which documents and fields are sent for a given connection.
• Reactivity contract is cursor based. The returned cursor determines which Oplog operations create diffs for that subscriber.

Smallest suitable design

Return a single cursor filtered by user identity and business rules, with a field projection for the minimum needed data.

// server/publish.js
Meteor.publish('postsByUser', function () {
  if (!this.userId) {
    return this.ready();
  }
  return Posts.find(
    { authorId: this.userId, status: 'published' },
    { fields: { title: 1, body: 1, createdAt: 1 } }
  );
});

Trust and data boundaries

Publish functions are the primary security boundary. They explicitly authorize which documents and fields reach each connected client.

Subscriptions rely on the Oplog tail for real‑time reactivity. The server watches operations that match the publish cursor and pushes only matching changes without re‑running the query.

Client‑side allow/deny rules are supplementary and should never be trusted as sole access control, as they execute in the browser and can be bypassed.

Operational checks

Verify the boundary from the server side.

• Use Meteor.isServer console logs and DDP connection traces to confirm that each subscriber receives only the intended document subset.
• Inspect publish return cursors against expected data schemas manually or via server‑side testing to validate access control boundaries.

Failure modes and redesign conditions

1. Over‑permissive publish. Returning an entire collection without filters exposes sensitive data and violates the trust boundary. If new sensitive fields are added later, they become visible to all subscribers. Redesign by adding a selector and projection, and by reviewing publishes when the schema changes.
2. Circular reactive dependencies. When a publish function depends on reactive state that is itself affected by the subscription result, update loops can form. Keep publish functions pure: depend only on database data and this.userId, not on client session variables.

Conditions that would change the design: need for per‑field access control, multi‑tenant isolation beyond userId, or large result sets that require pagination. In those cases move to parameterized publishes with explicit limits and separate methods for mutations.

Limitations and practical verification

Publish functions reduce attack surface but are not a replacement for server‑side access control for mutations. Methods must still enforce authorization.

A practical check is a server‑side test that subscribes with a known user, asserts the cursor shape matches the schema, and mutates documents outside the selector to confirm they are not sent. Ongoing production confidence comes from monitoring subscription counts and Oplog tail latency and alerting on sustained growth.