Emily Stark: Meteor Meets Mallory -- Devshop 6 Tech Talk
Why Stack Overflow recommends it
Stack Overflow users link it as the go-to explanation of how to secure a Meteor app, especially around input checking, methods and publishers, XSS and injection concerns.
Recommended by 3 people across 2 different months, 2014 to 2014.
What it is
A 2013 tech talk from Meteor Devshop 6 in which core developer Emily Stark, who researched JavaScript security and cryptography at Stanford and MIT, explains the Meteor security model. She compares it to a traditional web app and covers how to structure an app securely and defend against cross-site scripting and Mongo injection.
What people said
Recommends imslavko · 2014-02 · Stack Overflow · on “Meteor.js and CSRF/XSS Attacks”
Meteor's page rendering engine takes care of escaping special symbols when dealing with data bindings which saves from very basic XSS attacks. Also Meteor provides very easy to use APIs to control the browser policy ( [LINK] ) such as framing options or content policy options. It is worth mentioning the check [LINK] and audit-argument-checks [LINK] packages - those help you to validate user inputs based on their types to prevent MongoDB injections. CSRF attacks are not possible in Meteor as the framework itself doesn't use cookies at all and prefers HTML5 localStorage which is much harder to spoof. For advanced accounts permissions, checkout the meteor-roles package: [LINK] , you can impleme
Recommends David Weldon · 2014-02 · Stack Overflow · on “Meteor - What is the best process for securing forms and storing sensitive data”
I'd recommend watching any meteor videos where Emily Stark [LINK] talks about security. The Meteor Meets Mallory [this video] talk is especially helpful.
Recommends Oliver Lloyd · 2014-05 · Stack Overflow · on “Should I use a server method or Collection.insert() to insert a record using Meteor?”
I'm trying to decide between two methods for inserting a new document to a collection from the client using Meteor.js. Call a Server Method or using the db API directly. So, I can either access the db api directly on the client: MyCollection.insert(doc) Or, I can create a new Server Method (under the /server dir): Meteor.methods({ createNew: function(doc) { check(doc, etc) var id = MyCollection.insert(doc); return project_id; } }); And then call it from the client like this: Meteor.call('createNew', doc, function(error, result){ // Carry on }); Both work but as far as I can see from testing, I only benefit from latency compensation (the local cache updating and showing on the screen before t
Cites David Weldon · 2014-11 · Stack Overflow · on “How is Meteor secure?”
Yes, but only if the method fails to check its inputs and context. Fortunately, meteor provides the tools to make this task pretty straightforward. Let's look at an example method I used to answer this question [LINK] . sendMessage is a method which lets a user send a message in a chat room: Meteor.methods({ sendMessage: function(message, roomId) { check(message, String); check(roomId, String); if (!this.user) throw new Meteor.Error(401, 'You must be logged in.'); if (_.isEmpty(message)) throw new Meteor.Error(403, 'Message must not be empty.'); var room = Rooms.findOne(roomId); if (!room) throw new Meteor.Error(404, 'Room not found.'); if (!_.contains(room.members, this.userId)) throw new M
Cites David Weldon · 2014-12 · Stack Overflow · on “Security: minimizing the amount of 'inside' information revealed client side”
They aren't. How can you hide the schema if a user can read the source which manipulates it? The short answer is that if Emily Stark [this video] doesn't think this is a security concern, then neither do I. If, however, you can construct an attack vector which uses schema information and bypasses properly written methods and publishers (those which check for injection attacks), the I promise you the core devs would love to hear about it. :)