Meteor Guide: Security


This is the comment thread for an article in the Meteor Guide.

Read the article:

The comment thread for each article appears at the very bottom of the page. Use this thread to post:

  1. Interesting articles related to the content
  2. New ways to do things that aren’t covered in the Guide
  3. Suggestions for Guide improvements

Or anything else related to this topic that people could find useful!

Securing server methods

With regard to rate limiting methods, why not retrieve the method names from exports:

const LISTS_METHODS = _.chain(exports)
  .reject((k)=> { return k.startsWith('__') })

instead of hard coding them:

const LISTS_METHODS = _.pluck([
], 'name');

Then you don’t have to remember to update the rate limiting section when you add and remove methods.


That sounds pretty neat! It’s a bit of a hack though, maybe there’s a better way? Perhaps this is a good start. @tmeasday what do you think?


I think that snippet relies on export being implemented in terms of module.exports, which doesn’t seem particularly safe in the face of future alternate implementations. Is there a better way?


Methods could have rate limiting by default like accounts.


There’s a bug in my code above. It incorrectly passes the name of the method variable instead of the the value of the name key. It should be:

    const LISTS_METHODS = _.chain(exports)
      .reject(k=> k == undefined)


What I ended up doing for now was placing the DDP rate limiting code only in server/register-api.js. When naming my methods I use the format For example: lists.methods.insert. This allows me to filter them out from the other method handlers. Here’s an example register-api.js:

import { DDPRateLimiter } from 'meteor/ddp-rate-limiter';
import '../../api/lists/methods';
import '../../api/todos/methods';

const THROTTLE_METHODS = _.chain(Meteor.server.method_handlers)
  .filter(k=> k.includes('.methods.'))
  name(name) {
    return _.contains(THROTTLE_METHODS, name);
  // Rate limit per connection ID
  connectionId() { return true; },
}, 5, 1000);

Now when I add new method modules or edit existing ones I don’t have to worry about rate limiting.


Regarding the section “secret server code”: How am I supposed to import the secret file containing the implementation of updateWithSecretAlgorithm() only from server code? Since the imports are static and top-level only, both the server and the client code will eventually import this file. Or am I missing something?


You should use “require” directly, since as you noticed you can only use “import” at the top level.


I just posted a suggestion regarding how to secure server methods


The guides SSL section has a bad link:
See the help article about SSL on Galaxy.

The galaxy guide Let’s Encrypt section shows a Generate Certificate button that is supposed to set up SSL in 1 click. I don’t see that button in my Galaxy control panel. I just see a button to upload a certificate.


@rdagger it appears you’re still on the Developer Edition of Galaxy, not the latest Galaxy that includes access to new production-grade features like SEO prerendering, automated SSL certs, larger container sizes, and high-availability fault tolerance. If you’d like to upgrade, please send us a quick email at with your Meteor dev account name and we’ll make it happen!


Fixed the broken link:


Am I right in saying that you can now use import within the method directly now? Appears to be working fine for me.

Is this the best way of accessing ‘secret’ code from within a method currently?



Hey, thanks for the snippet.

I have a question about the best practice in adding rules, … would it be bad for performance if I added a rule per method …

I think it might be easier to use a mixin with each ValidatedMethod, something like this:

Are there any guidelines when using ddp rate limits, and should I treat publication the same as methods (with a rule foreach?)


Any guidance on how best to deal with sensitive data on the client before sending it over the wire? e.g. a user’s personal data, api keys, etc.?


Use SSL :sunglasses:

edit: Also, don’t send API keys to the client, unless they are meant to be public.


Instead of completely blocking off allow/deny, why not whitelist attributes?