I’ve been shouting about why you should check all of the user provided arguments in your Meteor applications for months now. Working with unchecked arguments can lead to a variety of serious security issues in your application.
But still, I find myself coming into client projects and security assessments where I see developers forgetting to check
their arguments!
The audit-argument-checks is a great package designed to get people to check all of their method and publication arguments. Unfortunately, it has its shortcomings.
audit-argument-checks
will only tell you that you’re missing check coverage for a method or publication at runtime, when that method or publication is called. The package politely informs you of this missing coverage by throwing an exception and killing the current method or publication.
What’s worse, audit-argument-checks
is not a debugOnly
package, so these exceptions will continue to be thrown in production releases, potentially breaking your application (arguably for good reason).
Wouldn’t it be great if we could get a report of missing checks at startup, rather than through exceptions at runtime? Now you can! Check out my newly released east5th:check-checker package.
meteor add east5th:check-checker
check-checker
was born of my need to quickly get informed about the state of argument checking in an application during a security assessment. It’s built on top of ESLint, and uses static analysis techniques to find all method and publication declarations in a Meteor application. If check
is not called on a method or publication argument within the body of the handler, a warning is shown in the server logs.
Imagine you have a file in your Meteor project, example.js
, that contains method and publication declarations with unchecked arguments:
if (Meteor.isServer) {
Meteor.methods({
foo: function(bar) {
return MyCollection.find();
}
});
Meteor.publish({
test: function(rab, oof) {
SensitiveDocuments.update(rab, oof);
}
});
}
After adding check-checker
, you’ll see the following warning in your server logs after the application starts:
/example.js:
Method 'foo' has an unchecked argument: bar
Publication 'baz' has an unchecked argument: rab
Publication 'baz' has an unchecked argument: oof
The goal of check-checker
is to make it easier for developers to quickly find where they’re lacking check coverage. The faster you can find the chinks in your armor, the faster you can secure your application.