4 ms·

I'm apprehensive of the security model. Everything is highly ease-of-use optimized, to the point that you can query Mongo via the browser console. My preferred

I'm apprehensive of the security model. Everything is highly ease-of-use optimized, to the point that you can query Mongo via the browser console. My preferred "easy/simple" model of app design is Firebase (backend and JS lib for pure web clients), who have security figured out.

sergiotapia 11y ago
What you're saying is only true on a barebones default Meteor app. Please don't comment on a tool if you've never used it for anything other than a hello world, you're doing a very sophisticated tool a huge disservice. You remove the autopublish package and you can no longer query records from the client.
- juliangregorian 11y ago
  There's no need to be rude. How many people are going to not know that, or forget? Meteor is highly tailored towards beginners. Additionally, Mongo's out-of-the-box security policies are extremely lax as well, and unsecured Mongo instances in the wild are a huge problem.
- matthewmacleod 11y ago
  I don't necessarily disagree with you, but it's still an astonishingly bad practice as a default. If there's one thing we should have learned from Rails' various security failures, it's that things must be secure by default.
- nostrademons 11y ago
  Anyone remember register_globals in PHP?
- debaserab2 11y ago
  There's no excuse for insecure defaults.
  - deleted 11y ago
    [deleted]
  - accounthere 11y ago
    It's more of a development default.
  - matthewdav 11y ago
    I disagreed, in OWASP: It is important to understand that by no means does “Secure Defaults” mean turning off all possible network applications or sockets and services. And neither do Secure Defaults mean a 100% secure environment. But, they should ensure the least number of possible loopholes and fewer drawbacks. Likewise, no matter what languages, majority are insecure by defaults.
    - debaserab2 11y ago
      What other tech stack allows you to publicly query the application data source by default? I think it's fair to say that shouldn't be possible and I'd be hard pressed to believe that OWASP would disagree with that.
- KurtMueller 11y ago
  Hi Sergio, One of the things I like about rails (and ember-cli) is that it is "secure-by-default". If I am going to make a choice that potentially has security vulnerabilities, I have to deliberately make that choice - I basically have to create a whitelist of things I want to allow.
- Xixi 11y ago
  A lot of software engineers are wary of frameworks/tools with an emphasize on ease-of-use over security, or benchmarking over data integrity. Rightly so in my opinion. It leaves a "I should triple check everything again before going live since I cannot trust the tool to do its job" thread running permanently in the back of the mind. It's such a slowdown. Don't get me wrong, it's important to read the documentation and double check settings, but insanity by default does not build trust. That said in the case of meteor beyond the autopublish package that should be off by default, I think everything is spot on. I mostly use PostgreSQL, so I cannot use it as much as I'd like to, but hopefully that will change.
  - sergiotapia 11y ago
    I agree with what you're saying, but a lot of people make it look like Meteor allows XSS and SQL Injection by default. You really only need to remove autopublish from the get go right after meteor create foobar and you begin with a secure app.
    - danellis 11y ago
      You should never have to do anything to become secure. The mantra is: secure by design; secure by default; secure by configuration.
      - matthewdav 11y ago
        In OWASP: It is important to understand that by no means does “Secure Defaults” mean turning off all possible network applications or sockets and services. And neither do Secure Defaults mean a 100% secure environment. But, they should ensure the least number of possible loopholes and fewer drawbacks.
imslavko 11y ago
Meteor's security model allows app developer to validate any operation or RPC going through, based on the arguments or userId (by writing JS code). Also, the published set is controlled by publications, allowing to publish only filtered out data with specific fields. Unlike Firebase, Meteor actually allows you to send "first top 20 guest posts from November" as an example. The filtering can happen on the server, before sending the data and the data model usually fits into a sets of documents in set of collections. In Firebase, everything is part of a big subtree that is not filterable (the last time I checked). Firebase is a good choice for keeping your real-time data. But knowing its limitations is as important as knowing its strengths.
- joeyyang 11y ago
  Hey there, I'm Joey, a Firebase dev — last November, we shipped advanced querying support[0] to address this! You can now use orderByChild(), orderByKey() or orderByPriority() to build a query. We also have limitToFirst(), limitToLast(), startAt(), endAt(), and equalTo() methods to further filter your data. This allows you to build queries like this: ref.orderByChild("weight").limitToLast(2).on("child_added", function(snapshot) { console.log(snapshot.key()); }); Please check out our querying docs[1], and let us know if you have any questions! [0] https://www.firebase.com/blog/2014-11-04-firebase-realtime-queries.html https://www.firebase.com/blog/2014-11-04-firebase-realtime-q... [1] https://www.firebase.com/docs/web/api/query/ https://www.firebase.com/docs/web/api/query/
  - imslavko 11y ago
    This is great! I didn't doubt that Firebase will roll out features to paginate and sort data. I also don't doubt that Firebase will implement filtering in the future. Great work.
jonlachlan 11y ago
> "Everything is ease-of-use optimized, to the point that you can query Mongo via the browser console." meteor remove autopublish meteor remove insecure The Mongo-accessible frontent is genius. This makes your prototyping much faster, and you can totally skip the "model" layer of your frontend. It matches your backend automatically. No further configuration needed. No REST endpoints, no callbacks. And yes, it's secure. Meteor's security model is very well-designed. The list of things left for the developer to do, security-wise, is very short. It's still important to learn your tools and understand how security works. http://docs.meteor.com/ http://docs.meteor.com/ http://security-resources.meteor.com/ http://security-resources.meteor.com/ https://github.com/themeteorchef/security-essentials https://github.com/themeteorchef/security-essentials https://www.youtube.com/watch?v=6_3pomxyp8M https://www.youtube.com/watch?v=6_3pomxyp8M

sergiotapia 11y ago

What you're saying is only true on a barebones default Meteor app. Please don't comment on a tool if you've never used it for anything other than a hello world, you're doing a very sophisticated tool a huge disservice. You remove the autopublish package and you can no longer query records from the client.

juliangregorian 11y ago
There's no need to be rude. How many people are going to not know that, or forget? Meteor is highly tailored towards beginners. Additionally, Mongo's out-of-the-box security policies are extremely lax as well, and unsecured Mongo instances in the wild are a huge problem.
matthewmacleod 11y ago
I don't necessarily disagree with you, but it's still an astonishingly bad practice as a default. If there's one thing we should have learned from Rails' various security failures, it's that things must be secure by default.
nostrademons 11y ago
Anyone remember register_globals in PHP?
debaserab2 11y ago
There's no excuse for insecure defaults.
- deleted 11y ago
  [deleted]
- accounthere 11y ago
  It's more of a development default.
- matthewdav 11y ago
  I disagreed, in OWASP: It is important to understand that by no means does “Secure Defaults” mean turning off all possible network applications or sockets and services. And neither do Secure Defaults mean a 100% secure environment. But, they should ensure the least number of possible loopholes and fewer drawbacks. Likewise, no matter what languages, majority are insecure by defaults.
  - debaserab2 11y ago
    What other tech stack allows you to publicly query the application data source by default? I think it's fair to say that shouldn't be possible and I'd be hard pressed to believe that OWASP would disagree with that.
KurtMueller 11y ago
Hi Sergio, One of the things I like about rails (and ember-cli) is that it is "secure-by-default". If I am going to make a choice that potentially has security vulnerabilities, I have to deliberately make that choice - I basically have to create a whitelist of things I want to allow.
Xixi 11y ago
A lot of software engineers are wary of frameworks/tools with an emphasize on ease-of-use over security, or benchmarking over data integrity. Rightly so in my opinion. It leaves a "I should triple check everything again before going live since I cannot trust the tool to do its job" thread running permanently in the back of the mind. It's such a slowdown. Don't get me wrong, it's important to read the documentation and double check settings, but insanity by default does not build trust. That said in the case of meteor beyond the autopublish package that should be off by default, I think everything is spot on. I mostly use PostgreSQL, so I cannot use it as much as I'd like to, but hopefully that will change.
- sergiotapia 11y ago
  I agree with what you're saying, but a lot of people make it look like Meteor allows XSS and SQL Injection by default. You really only need to remove autopublish from the get go right after meteor create foobar and you begin with a secure app.
  - danellis 11y ago
    You should never have to do anything to become secure. The mantra is: secure by design; secure by default; secure by configuration.
    - matthewdav 11y ago
      In OWASP: It is important to understand that by no means does “Secure Defaults” mean turning off all possible network applications or sockets and services. And neither do Secure Defaults mean a 100% secure environment. But, they should ensure the least number of possible loopholes and fewer drawbacks.

imslavko 11y ago

Meteor's security model allows app developer to validate any operation or RPC going through, based on the arguments or userId (by writing JS code). Also, the published set is controlled by publications, allowing to publish only filtered out data with specific fields. Unlike Firebase, Meteor actually allows you to send "first top 20 guest posts from November" as an example. The filtering can happen on the server, before sending the data and the data model usually fits into a sets of documents in set of collections. In Firebase, everything is part of a big subtree that is not filterable (the last time I checked). Firebase is a good choice for keeping your real-time data. But knowing its limitations is as important as knowing its strengths.

joeyyang 11y ago
Hey there, I'm Joey, a Firebase dev — last November, we shipped advanced querying support[0] to address this! You can now use orderByChild(), orderByKey() or orderByPriority() to build a query. We also have limitToFirst(), limitToLast(), startAt(), endAt(), and equalTo() methods to further filter your data. This allows you to build queries like this: ref.orderByChild("weight").limitToLast(2).on("child_added", function(snapshot) { console.log(snapshot.key()); }); Please check out our querying docs[1], and let us know if you have any questions! [0] https://www.firebase.com/blog/2014-11-04-firebase-realtime-queries.html https://www.firebase.com/blog/2014-11-04-firebase-realtime-q... [1] https://www.firebase.com/docs/web/api/query/ https://www.firebase.com/docs/web/api/query/
- imslavko 11y ago
  This is great! I didn't doubt that Firebase will roll out features to paginate and sort data. I also don't doubt that Firebase will implement filtering in the future. Great work.

jonlachlan 11y ago

> "Everything is ease-of-use optimized, to the point that you can query Mongo via the browser console." meteor remove autopublish meteor remove insecure The Mongo-accessible frontent is genius. This makes your prototyping much faster, and you can totally skip the "model" layer of your frontend. It matches your backend automatically. No further configuration needed. No REST endpoints, no callbacks. And yes, it's secure. Meteor's security model is very well-designed. The list of things left for the developer to do, security-wise, is very short. It's still important to learn your tools and understand how security works. http://docs.meteor.com/ http://docs.meteor.com/ http://security-resources.meteor.com/ http://security-resources.meteor.com/ https://github.com/themeteorchef/security-essentials https://github.com/themeteorchef/security-essentials https://www.youtube.com/watch?v=6_3pomxyp8M https://www.youtube.com/watch?v=6_3pomxyp8M