Pete Corey Writing Work Contact

Meteor Club Q&A on Security

Written by Pete Corey on Dec 14, 2015.

A few weeks ago, I had the chance to do a Meteor Club Q&A with Josh Owens. We spent an hour or so talking about various topics revolving around Meteor and Meteor security and answering questions submitted by the community. The whole process was a lot of fun. You should check out the whole Q&A on Youtube, or take a look below:

During the Q&A, we covered a variety of topics ranging from data-in-motion/data-at-rest security, to the positives and negatives of collection validators, all the way through to best practices for securing multi-tenant Meteor applications.

Do you have any questions about Meteor security that we didn’t discuss in the Q&A? If so, shoot me a tweet, or send me an email!

Scanning Meteor Projects for Node Vulnerabilities

Written by Pete Corey on Dec 7, 2015.

Meteor does not exist in a bubble. All of Meteor is built on top of Node.js. This means that while security projects like east5th:package-scan can help us find Meteor specific security problems in our projects, we may still be vulnerable to an entire world of vulnerabilities that exist within the Node ecosystem.

There are many Node tools that, like east5th:package-scan, will dig through the Node packages being used by your project and alert you if it finds any packages with known security vulnerabilities.

Two great tools that do this are the Node Security Project and Snyk. While these tools are designed to be used with a vanilla Node project, with a little convincing it’s possible to use them in the context of a Meteor project.

Anatomy of a Bundle

It can be difficult to determine which Node packages are being used by a Meteor application. Each Meteor package can pull in its own set of Npm packages, and these dependencies can be difficult to see unless the Meteor package has been explicitly cloned into the PACKAGE_DIRS directory.

Thankfully, a bundled Meteor application pulls all of these dependencies into a single location. Once an application is bundled, we can dig into the server Node project (found in .build/bundle/programs/server). From there we can browse through all of the Node dependencies being used by our various Meteor packages: npm/*/node_modules/*.

A brand new Meteor project (meteor create foo) immediately pulls in over a dozen Node packages. Check them out:

├── babel-compiler         <- Meteor package
│   └── node_modules
│       └── meteor-babel   <- Node package
├── ddp-client
│   └── node_modules
│       ├── faye-websocket
│       └── permessage-deflate
├── ddp-server
│   └── node_modules
│       ├── permessage-deflate
│       └── sockjs
├── ecmascript-runtime
│   └── node_modules
│       └── meteor-ecmascript-runtime
├── es5-shim
│   └── node_modules
│       └── es5-shim
├── logging
│   └── node_modules
│       └── cli-color
├── meteor
│   └── node_modules
│       └── meteor-deque
├── mongo
│   └── node_modules
│       └── mongodb-uri
├── npm-mongo
│   └── node_modules
│       └── mongodb
├── promise
│   └── node_modules
│       └── meteor-promise
└── webapp
    └── node_modules
        ├── connect
        ├── send
        └── useragent

Using Node Security Project

We can navigate into any of these Node package directories and run an NSP scan. For example, we can check the sockjs package use by ddp-server like this:

cd .build/bundle/programs/server/npm/ddp-server/node_modules/sockjs
nsp check

Thankfully, there are no known vulnerabilities in this Node package:

(+) No known vulnerabilities found

We could manually run this check for each Node package, but that would be incredibly time consuming. Why not automate the process?

I wrote a quick bash script that looks for each package.json found within these top-level Node project folders and runs NSP on them. Here’s the script:

#!/usr/bin/env bash

find bundle/programs/server/npm/*/node_modules/*/package.json |
while read file; do
  DIR="$(dirname $file)"
  pushd "${DIR}" > /dev/null
  OUTPUT="$(nsp check --output summary --color)"
  if [ $? != 0 ]; then
    echo -e "${OUTPUT}"
  popd > /dev/null

I named this script mscan and threw it into my ~/bin folder. To use it, build your meteor project, navigate into the newly created build directory, and run the script:

meteor build --directory .build &&
cd .build &&

Even for a brand new Meteor project, the results of this scan are somewhat suprising:

(+) 3 vulnerabilities found
 Name        Installed   Patched     Path   More Info
 uglify-js   2.2.5       >=2.6.0  
 uglify-js   2.2.5       >= 2.4.24
 uglify-js   2.4.24      >=2.6.0  

(+) 4 vulnerabilities found
 Name   Installed   Patched    Path             More Info
 send   0.1.4       >=0.11.1   connect > send
 send   0.1.4       >= 0.8.4   connect > send
 qs     0.6.5       >= 1.x     connect > qs
 qs     0.6.5       >= 1.x     connect > qs

It looks like Meteor core is pulling in a few Node packages with known security issues. Very interesting! It’s worth taking a look at these advisories and considering what impact (if any) they might have on your Meteor application.

Drawbacks and Final Thoughts

One thing to note about the NSP tool is that it will only scan the dependencies found in a package.json file for vulnerabilities. It will not check if the package itself has any known issues. This means that if we run nsp check on the mongodb Node package, it will only report any vulnerabilities in mongodb’s dependencies, not any vulnerabilities with the package itself.

This is a known issue and the Node Security Project team are actively working on a fix.

The bash script I created to do these scans certainly isn’t the most user friendly tool. If you find it interesting or useful, I can give it a little more love and turn it into a Npm-installable command line tool, which may be more straight-forward to use.

Giving Thanks

Written by Pete Corey on Nov 30, 2015.

Maybe it’s the pumpkin pie talking, but the spirit of thankfulness is flowing through me today. I want to take a minute to stop and reflect on the past year and give thanks where thanks is due.

A little over one year ago I started seriously experimenting with Meteor as a platform. Coming from a Java and PHP background and cobbling together front-ends with everything from Flex to AngluarJS and everything in-between, Meteor was a breath of fresh air. It let me focus on getting things done, rather than focusing on how to get things done.

The productivity boost I experienced when switching to Meteor was a game changer for my career. At the same time I was first digging into Meteor I decided to pursue full-time self employment. I opened up shop under the East5th name, and after my first year of business, I fully recognize that much of my success as a freelance developer and consultant is thanks to the technical foundation Meteor and the Meteor Development Group built out for me.

Thank you Meteor!

I’ve spent this past year intentionally investing more time into writing and creating content, and the results have been spectacular. Taking the time each week to write small blog posts and articles about various Meteor and software development topics has led to a huge outpouring of support and acceptance from the community.

On average, this blog gets approximately four thousand readers per month, and many of those people have become my close friends and colleagues. Many of those friends have offered invaluable help and advice throughout the year. I’m sincerely grateful to everything they’ve done for me, what they’ve helped me accomplish, and the opportunities they’ve given me.

Every Monday morning I push out some piece of content and eagerly wait for feedback from all of you. Your comments, questions, and suggestions truly help me grow as a developer. Hopefully something I write helps you as well.

I’m unimaginably excited about what the next few years will bring, and I hope I get to know a lot of you much better during that time!

If you want to get in touch, tweet me, or shoot me an email.

Thanks for reading!