Secure Meteor Publications: Limiting Data Over-Fetch with Field Selectors

The problem: accidental data exposure

When you create a Meteor publication without limiting the fields sent to the client, every document in the collection is streamed to all subscribed users. If your collection contains sensitive data such as password hashes, email addresses, or internal flags, a mis‑configured allow rule or a missing field selector can leak that information to anyone who can open the browser console and inspect the subscription.

Thesis: use explicit field selectors and deny rules to enforce a least‑privilege data flow

By declaring which fields a publication should send and pairing that with server‑side allow rules that deny writes unless explicitly permitted, you keep the reactive UI benefits of Meteor while preventing accidental over‑fetch. This approach works across Meteor 1.8+ (including the current 3.x line) and requires only a few lines of server and client code.

Understanding the default behavior

A publication defined as:

// server/publications.js
Meteor.publish('posts', function () {
  return Posts.find();
});

sends every field of every posts document to the client. The client’s Minimongo cache will contain the full document, and any client‑side code can read those fields.

Field selectors in publications

You can restrict the fields by passing a second argument to find:

// server/publications.js
Meteor.publish('posts', function () {
  return Posts.find({}, { fields: { title: 1, authorId: 1, createdAt: 1 } });
});

Now only title, authorId, and createdAt are transmitted. If you later add a new field such as internalNotes, it will not appear unless you explicitly add it to the selector.

Pairing with deny rules

Field selectors protect reads, but write permissions are controlled by allow/deny rules on the collection. A safe default is to deny all writes and then enable specific operations:

// server/collections.js
Posts.deny({
  insert: () => true,
  update: () => true,
  remove: () => true
});

Posts.allow({
  insert: function (userId, doc) {
    return !!userId && doc.authorId === userId;
  },
  update: function (userId, doc, fieldNames, modifier) {
    // only allow updating title and body
    return !!userId && _.difference(fieldNames, ['title', 'body']).length === 0;
  }
});

With this setup, even if a malicious client somehow subscribes to a publication that inadvertently leaks a field, they cannot modify it unless the allow rule explicitly permits the operation.

Worked example: publishing a blog post list

Imagine a blog where each post has:

• title (public)
• body (public)
• authorId (public)
• createdAt (public)
• isDraft (private)
• internalNotes (private)

We want the client to receive only the public fields for the list view, while the edit page subscribes to a different publication that includes the body and draft flag for the current user.

Server code

// server/publications.js
import { Meteor } from 'meteor/meteor';
import { Posts } from '../imports/api/posts.js';

// List view: only fields needed for the index
Meteor.publish('posts.list', function () {
  return Posts.find({ isDraft: { $ne: true } }, {
    fields: {
      title: 1,
      authorId: 1,
      createdAt: 1
    }
  });
});

// Edit view: send body and draft flag, but only if the user owns the post
Meteor.publish('posts.edit', function (postId) {
  check(postId, String);
  const post = Posts.findOne(postId);
  if (!post) return this.ready();
  if (post.authorId !== this.userId) {
    this.error('not-authorized');
    return this.stop();
  }
  return Posts.find(postId, {
    fields: {
      body: 1,
      isDraft: 1,
      title: 1,
      authorId: 1,
      createdAt: 1
    }
  });
});

Client subscription (list view)

// client/main.js or inside a template's onCreated
import { Meteor } from 'meteor/meteor';

Meteor.subscribe('posts.list');

Verifying the result

Open the browser console and run:

// Assuming the subscription is ready
Posts.find().fetch().map(doc => Object.keys(doc));

You should see arrays containing only ["title", "authorId", "createdAt", "_id"]. The private fields isDraft and internalNotes will be absent.

Trade‑offs and limitations

Field‑selector publications increase server‑side CPU usage slightly because MongoDB must project fields before sending them over the wire. In most apps this cost is negligible compared to the security gain. However, if you need to send a large subset of fields that changes frequently, maintaining multiple publications can become tedious. In such cases consider using a package like publish-composite to build relational projections while still applying field selectors at each level.

Another limitation is schema drift: if you add a new field to a collection and forget to update the relevant publications, the field will simply be omitted from the client, which may cause UI bugs. A practical mitigation is to write a test that subscribes to each publication and asserts that the expected set of fields is present.

Actionable checklist

1. Audit all existing publications: ensure each includes a fields selector that lists only the data the client truly needs.
2. Set default deny rules on every collection and whitelist specific insert/update/remove operations with allow.
3. When adding a new collection field, update the fields selector in every publication that should expose it, or add a new publication if the field is needed elsewhere.
4. Verify in the browser console that the client’s Minimongo contains only the expected fields after each subscription.
5. Run meteor release and compare against the official Meteor version table to confirm you are on a supported release (1.8+ or 3.x) before adding new features.