Hacker News Reader

Comment by sergiotapia | Hacker News Reader

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.

View on HN

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.

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.

There's no excuse for insecure defaults.

It's more of a development default.

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.

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.

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.

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.

You should never have to do anything to become secure. The mantra is: secure by design; secure by default; secure by configuration.

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.

Anyone remember register_globals in PHP?

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.

Reply on news.ycombinator.com