7 ms·

Can Firebase/Meteor ever be secure?

82 points by tg3 15y ago

willvarfar 15y ago
The moment some twit goes and writes a script to systematically wipe these servers, and there'll be a whole new flood of articles on HN/reddit ;)
mayop100 15y ago
(Founder of Firebase here) - The answer here is an emphatic, unequivocal yes. What BaaS providers like us do is create generic apis to allow developers to do the common operations that already can do with their own server code. Everything that can be done with your own server code can be done with our server code. So if it's possible for you to write your own secure server, then it's possible for a BaaS to do the same. The trick here is designing an API that is simple and easy to use that still works for a large set of use cases, and this is a very difficult task. Security is complicated, so making a generic, simple API tends to lead to APIs that apply to a reduced set of problems. Any particular BaaS system will likely not solve every security scenario available, but that doesn't mean ones can't be built that solve the vast majority of the scenarios that matter. Firebase is working hard on building this API, and we're doing it with a lot of careful diligence and input from our users. We're nowhere near done with it, but we're confident that when we are, we'll have a simple, powerful security model that works well and is secure for most apps without needing any server code, and for those apps with more complicated needs, we make it easy to hook up your own servers too.| Also, I'm very excited you got your app working in 5 minutes : )
- mckoss 15y ago
  Agreed. If you can provide an generic implementation able to work across many applications, you save everyone from having to reinvent the wheel - at the cost of delegating a portion of your app to the service host. The model I used in pageforest.com is to enable users to secure their documents as public, private, or shared access with other named users. Some apps don't fit in these neat categories, so a more complex system would be needed to support them.
- Animus7 15y ago
  > The trick here is designing an API that is simple and easy to use that still works for a large set of use cases, and this is a very difficult task. Security is complicated, so making a generic, simple API tends to lead to APIs that apply to a reduced set of problems. I completely agree, and I think you understand the issue. I'm just not convinced that any meaningful definition of app-specific "security" can be achieved concurrently with the kind of simplicity that underpins your value prop. If I have to go and cook up logic validation, ACLs, and who knows what just to make sure my app isn't trivially broken by anyone with a JS console, aren't I basically doing the server-side programming that your pitch says you're trying to eliminate? Except in a less familiar fashion? I'm not saying this is unfixable; I hope you have novel insights, and I want to be wrong. But I've always been sceptical of the free lunch.
  - mayop100 15y ago
    We're working hard to make this possible! Hopefully you'll be impressed with what we're cooking up when it's ready.
    - buu700 15y ago
      Out of curiosity, how complete is your security system right now? As in, if the code were frozen and documented as-is, would it be generally acceptable to use in production as far as you've tested (ignoring the occasional non-critical hiccup here and there)? I noticed that your FAQ offers beta testers the option of trying out what you have. Does this mean that it's at least functional for simple/common use cases?
- CrypticSwarm 15y ago
  I completely agree. It is entirely possible to secure with the appropriate API's. Operations can be rejected by the server. If done correctly the client side can have an optimistic UI that is also secure. (Optimistic UI's don't need to wait for an ack from the server. They display local changes immediately and roll back if server denies.)
  - ___Calv_Dee___ 15y ago
    But that just adds to the complexity that the "BaaS" is aiming to remove?
- dantheman 15y ago
  What does BaaS stand for?
  - ceejayoz 15y ago
    Backend as a Service, I'd guess.
shykes 15y ago
I think it's perfectly doable - but it will require custom validation to run on the server. I like that Meteor embraces that reality, although their implementation is not complete nor documented. The Firebase/Parse/Stackmob approach of API-driven ACLs and "zero code in the backend" adequately covers certain common use cases, but completely breaks down when you need something more custom - and, inevitably, you will. Sooner or later these guys will need to run your code on their servers (or their API will expose a dsl for querying/transformation/acl complex enough to be called "code"). I do like that mayop100 mentions they'll "make it easy to hook up your own servers too", although I'm not sure what that means in practice?
- mayop100 15y ago
  The basic idea for hooking up a server, is that the server will act like any other client, except it will authenticate with an API key and have full read / write access. This server can perform data validation for you. All you need to do is have a "unvalidated" bucket where clients put their data, and then have your server have callbacks that validate that data and copy it over into the "validated" bucket (where clients do not have write access) when everything checks out. This would need to be in concert with ACL's to prevent clients from writing in each other's buckets. Note that you still get the major advantages of Firebase -- simpler code, easy scaling, data accessibility, and real-time, even though you're running a server.
- jamroom 15y ago
  Check out Trestle: https://www.trestleapp.com/services/custom https://www.trestleapp.com/services/custom we're already running custom NodeJS code for our customers - along with the 14 other API services we have (including our Chain server) you can do a ton. It all is tied in to our ACL's too, so your custom service works the same as any other API service. We're also super happy to run it on DotCloud too ;)
  - shykes 15y ago
    Nice! I'll check it out.
Void_ 15y ago
The issue is bigger: All of the business logic is on the client side. You will, eventually, have to move some of the logic to the server side. I'm sure that it is/will be possible with Meteor/Firebase, but it's not as easy as writing a Rails app.
- mayop100 15y ago
  Actually, no, you won't. Before SaaS apps, all applications were client side. Microsoft Office, for instance, is a fully client-side application.
  - bonaldi 15y ago
    ... And, setting aside that Office is compiled, Office stores its files locally. When then those files move to shared space like servers, those servers get their own authentication and controls. Unless you're really saying the Firebase can only be used securely for client apps that live entirely on the client and don't need a server at all? I hope not. I was very interested to see what the answer is here, but the answers from the team didn't give me confidence that there is one, or that they were treating the problem with enough gravity. Then I see answers like this one, which give me the fear. Business logic that clients can access and change isn't a security hole, it's a security catastrophe. Until it can be protected, you can't build anything more than toys with this.
    - mayop100 15y ago
      Security for the data in Firebase is one issue - and as I've mentioned above we're taking that very seriously, and we're working on it. The business implications of having client-side software are a different issue, and I think its been demonstrated many times that businesses can do very well even with most or all of their code running client-side. Any desktop / mobile software works like this, as I mentioned. Relying on a compiler for security is a bad idea, just as you shouldn't rely on people not messing with your javascript. Clients today can access and change MS Office if they know what they are doing.
voidfiles 15y ago
You could use third party auth, like facebooks. you could use an iFrame on another domain to setup all the secure stuff, and then use something like easyXDM to communicate with that iFrame.
saurik 15y ago
Look at how Parse does ACL and user authentication (which might be difficult as their documentation isn't well-organized). General idea: you add the concept of "accounts" to the database API, have the server support the password reset emails (as you can't trust the client app code), and thn use session tokens for validation. So yes: trivially obviously possible, but with irritating data structuring issues (to make the ACL grnular in the places you need).
qznc 15y ago
Restricting database access is one aspect of security with Firebase. Much more interesting is the cross-site scripting problem. For example, firebase.com pulls in Javascript from Twitter and Google. Is Firebase safe from the other code on the same page?
eaurouge 15y ago
Am I missing something here? Just because you can request data and functionality from the client doesn't mean you'll get said data or functionality. On Meteor the database API is the same on client and server, but that's just an API. A Mongo command on the client doesn't go directly to MongoDB on the server. You could have an access layer (or controller) on the server thru which all client requests are passed. And this access layer determines which client requests are relayed to the database. It seems to me the question isn't whether Meteor/Firebase can be made secure, but which implementation would be best for client responsiveness, developer effort etc.
- bonaldi 15y ago
  You're missing that the pitch with Fireball at least is there is no server code as such. To which everyone is pointing out "what about the business logic and validation?". The answers so far seem to be "we'll come up with, er, something in future" and "Microsoft Office is all client-side". EDIT: To clarify I'm not talking about Meteor here.
  - geoffschmidt 15y ago
    That's not part of the pitch for Meteor. Take a look at point 6 on the Meteor homepage: Sensitive code runs in a privileged environment: Write all of your code in JavaScript (if you want.) The user interface runs in your browser. The sensitive functions run in a privileged server environment.
  - Lazare 15y ago
    That's simply untrue, at least as far as Meteor goes. One of their big selling points is, in fact, that there IS server code.
  - eaurouge 15y ago
    You're missing that the pitch with these things is there is no server code as such. For Firebase, yes that is part of the pitch. Personally the use case for Firebase doesn't really appeal to me. For Meteor, it's the opposite. The fact that you can write some server-only code is a plus.
minimaxir 15y ago
What about nonces? Have the Meteor server create a unique nonce per user per instance of DB action, then verify it serverside.

82 points by tg3 15y ago

The moment some twit goes and writes a script to systematically wipe these servers, and there'll be a whole new flood of articles on HN/reddit ;)

mayop100 15y ago

(Founder of Firebase here) - The answer here is an emphatic, unequivocal yes. What BaaS providers like us do is create generic apis to allow developers to do the common operations that already can do with their own server code. Everything that can be done with your own server code can be done with our server code. So if it's possible for you to write your own secure server, then it's possible for a BaaS to do the same. The trick here is designing an API that is simple and easy to use that still works for a large set of use cases, and this is a very difficult task. Security is complicated, so making a generic, simple API tends to lead to APIs that apply to a reduced set of problems. Any particular BaaS system will likely not solve every security scenario available, but that doesn't mean ones can't be built that solve the vast majority of the scenarios that matter. Firebase is working hard on building this API, and we're doing it with a lot of careful diligence and input from our users. We're nowhere near done with it, but we're confident that when we are, we'll have a simple, powerful security model that works well and is secure for most apps without needing any server code, and for those apps with more complicated needs, we make it easy to hook up your own servers too.| Also, I'm very excited you got your app working in 5 minutes : )

mckoss 15y ago
Agreed. If you can provide an generic implementation able to work across many applications, you save everyone from having to reinvent the wheel - at the cost of delegating a portion of your app to the service host. The model I used in pageforest.com is to enable users to secure their documents as public, private, or shared access with other named users. Some apps don't fit in these neat categories, so a more complex system would be needed to support them.
Animus7 15y ago
> The trick here is designing an API that is simple and easy to use that still works for a large set of use cases, and this is a very difficult task. Security is complicated, so making a generic, simple API tends to lead to APIs that apply to a reduced set of problems. I completely agree, and I think you understand the issue. I'm just not convinced that any meaningful definition of app-specific "security" can be achieved concurrently with the kind of simplicity that underpins your value prop. If I have to go and cook up logic validation, ACLs, and who knows what just to make sure my app isn't trivially broken by anyone with a JS console, aren't I basically doing the server-side programming that your pitch says you're trying to eliminate? Except in a less familiar fashion? I'm not saying this is unfixable; I hope you have novel insights, and I want to be wrong. But I've always been sceptical of the free lunch.
- mayop100 15y ago
  We're working hard to make this possible! Hopefully you'll be impressed with what we're cooking up when it's ready.
  - buu700 15y ago
    Out of curiosity, how complete is your security system right now? As in, if the code were frozen and documented as-is, would it be generally acceptable to use in production as far as you've tested (ignoring the occasional non-critical hiccup here and there)? I noticed that your FAQ offers beta testers the option of trying out what you have. Does this mean that it's at least functional for simple/common use cases?
CrypticSwarm 15y ago
I completely agree. It is entirely possible to secure with the appropriate API's. Operations can be rejected by the server. If done correctly the client side can have an optimistic UI that is also secure. (Optimistic UI's don't need to wait for an ack from the server. They display local changes immediately and roll back if server denies.)
- ___Calv_Dee___ 15y ago
  But that just adds to the complexity that the "BaaS" is aiming to remove?
dantheman 15y ago
What does BaaS stand for?
- ceejayoz 15y ago
  Backend as a Service, I'd guess.

shykes 15y ago

I think it's perfectly doable - but it will require custom validation to run on the server. I like that Meteor embraces that reality, although their implementation is not complete nor documented. The Firebase/Parse/Stackmob approach of API-driven ACLs and "zero code in the backend" adequately covers certain common use cases, but completely breaks down when you need something more custom - and, inevitably, you will. Sooner or later these guys will need to run your code on their servers (or their API will expose a dsl for querying/transformation/acl complex enough to be called "code"). I do like that mayop100 mentions they'll "make it easy to hook up your own servers too", although I'm not sure what that means in practice?

mayop100 15y ago
The basic idea for hooking up a server, is that the server will act like any other client, except it will authenticate with an API key and have full read / write access. This server can perform data validation for you. All you need to do is have a "unvalidated" bucket where clients put their data, and then have your server have callbacks that validate that data and copy it over into the "validated" bucket (where clients do not have write access) when everything checks out. This would need to be in concert with ACL's to prevent clients from writing in each other's buckets. Note that you still get the major advantages of Firebase -- simpler code, easy scaling, data accessibility, and real-time, even though you're running a server.
jamroom 15y ago
Check out Trestle: https://www.trestleapp.com/services/custom https://www.trestleapp.com/services/custom we're already running custom NodeJS code for our customers - along with the 14 other API services we have (including our Chain server) you can do a ton. It all is tied in to our ACL's too, so your custom service works the same as any other API service. We're also super happy to run it on DotCloud too ;)
- shykes 15y ago
  Nice! I'll check it out.

Void_ 15y ago

The issue is bigger: All of the business logic is on the client side. You will, eventually, have to move some of the logic to the server side. I'm sure that it is/will be possible with Meteor/Firebase, but it's not as easy as writing a Rails app.

mayop100 15y ago
Actually, no, you won't. Before SaaS apps, all applications were client side. Microsoft Office, for instance, is a fully client-side application.
- bonaldi 15y ago
  ... And, setting aside that Office is compiled, Office stores its files locally. When then those files move to shared space like servers, those servers get their own authentication and controls. Unless you're really saying the Firebase can only be used securely for client apps that live entirely on the client and don't need a server at all? I hope not. I was very interested to see what the answer is here, but the answers from the team didn't give me confidence that there is one, or that they were treating the problem with enough gravity. Then I see answers like this one, which give me the fear. Business logic that clients can access and change isn't a security hole, it's a security catastrophe. Until it can be protected, you can't build anything more than toys with this.
  - mayop100 15y ago
    Security for the data in Firebase is one issue - and as I've mentioned above we're taking that very seriously, and we're working on it. The business implications of having client-side software are a different issue, and I think its been demonstrated many times that businesses can do very well even with most or all of their code running client-side. Any desktop / mobile software works like this, as I mentioned. Relying on a compiler for security is a bad idea, just as you shouldn't rely on people not messing with your javascript. Clients today can access and change MS Office if they know what they are doing.

voidfiles 15y ago

You could use third party auth, like facebooks. you could use an iFrame on another domain to setup all the secure stuff, and then use something like easyXDM to communicate with that iFrame.

saurik 15y ago

Look at how Parse does ACL and user authentication (which might be difficult as their documentation isn't well-organized). General idea: you add the concept of "accounts" to the database API, have the server support the password reset emails (as you can't trust the client app code), and thn use session tokens for validation. So yes: trivially obviously possible, but with irritating data structuring issues (to make the ACL grnular in the places you need).

qznc 15y ago

Restricting database access is one aspect of security with Firebase. Much more interesting is the cross-site scripting problem. For example, firebase.com pulls in Javascript from Twitter and Google. Is Firebase safe from the other code on the same page?

eaurouge 15y ago

Am I missing something here? Just because you can request data and functionality from the client doesn't mean you'll get said data or functionality. On Meteor the database API is the same on client and server, but that's just an API. A Mongo command on the client doesn't go directly to MongoDB on the server. You could have an access layer (or controller) on the server thru which all client requests are passed. And this access layer determines which client requests are relayed to the database. It seems to me the question isn't whether Meteor/Firebase can be made secure, but which implementation would be best for client responsiveness, developer effort etc.

bonaldi 15y ago
You're missing that the pitch with Fireball at least is there is no server code as such. To which everyone is pointing out "what about the business logic and validation?". The answers so far seem to be "we'll come up with, er, something in future" and "Microsoft Office is all client-side". EDIT: To clarify I'm not talking about Meteor here.
- geoffschmidt 15y ago
  That's not part of the pitch for Meteor. Take a look at point 6 on the Meteor homepage: Sensitive code runs in a privileged environment: Write all of your code in JavaScript (if you want.) The user interface runs in your browser. The sensitive functions run in a privileged server environment.
- Lazare 15y ago
  That's simply untrue, at least as far as Meteor goes. One of their big selling points is, in fact, that there IS server code.
- eaurouge 15y ago
  You're missing that the pitch with these things is there is no server code as such. For Firebase, yes that is part of the pitch. Personally the use case for Firebase doesn't really appeal to me. For Meteor, it's the opposite. The fact that you can write some server-only code is a plus.

minimaxir 15y ago

What about nonces? Have the Meteor server create a unique nonce per user per instance of DB action, then verify it serverside.