

Be careful when going client-only (Firebase) - foofoobar
http://robinverton.de/blog/2013/08/27/be-careful-when-going-client-only-firebase/

======
jamest
[Firebase Founder] Hi Robin,

You’re right, some folks don’t fully setup their security rules. We remind our
developers to do this, but can -- and clearly need -- to do more. Your
suggestion about requiring security rules is a good one. We’ll be going
through our customers and providing more personalized feedback on their
security rules in the coming days. Also, we are working on additional
tutorials and examples to teach our devs how to use our security rules in an
interactive way.

Thanks for pointing out some of the areas we can improve our examples. They’re
intended to illustrate design patterns, not be robust production apps. Again,
we can do better here, and the code we use as an example should be bullet
proof.

Like any application, Firebase-powered apps are only as secure as the
developers make them. If you do not control access with security rules, your
app could be vulnerable. XSS attacks can affect Firebase apps like any other
application.

Finally, we would have really liked you to provide responsible disclosure on
the specific Firebases you found issue with and given us enough time to speak
with those customers before taking this public.

We’ll reach out to you via email now.

~~~
patio11
So good news and bad news, bad news first: There doesn't appear to be a
Firebase security contact page where you spell out how to get in touch with
you if a researcher discovers something like this. Industry standard practice
is, for better or worse, if you do not have that page then any available
textarea is an acceptable method for communication with you about security
vulnerabilities in your software.

The good news: you can trivially address this by adding one page in your CMS,
calling it "Security", writing a few sentences of copy, and adding a) an email
address which is monitored, b) a promise to write back, and c) (optional) a
PGP key.

Some good examples:

[http://www.twilio.com/docs/security/disclosure](http://www.twilio.com/docs/security/disclosure)

[http://37signals.com/security-response](http://37signals.com/security-
response)

[http://technet.microsoft.com/en-
us/security/ff852094.aspx](http://technet.microsoft.com/en-
us/security/ff852094.aspx)

P.S. This advice is broadly applicable to everyone here who owns or helps to
manage a software company.

~~~
jamest
Thanks Patrick. Point well taken.

I'll add one now.

------
coderaptor
Firebase's solution isn't difficult to configure, it's just more difficult
when you contrast it with the simplicity and grace provided by the rest of
their product.

My startup is addressing the usability mainly by acting as a proxy to a
client's sensitive data storage, and providing a sane set of defaults for very
specific applications.

This space is awesome, and so is Firebase - Client-side apps are incredibly
attractive for MVP development - it's almost as slick a feeling as moving from
PHP to Rails 10 years ago :)

------
hrjet
Completely agree with the implications in this article. My experience in
building a Firebase app was that it was easy to design the app's first cut, as
long as security / privacy was not taken care of.

As soon as security / privacy / quota needs to be factored in, the whole model
collapses. Security requires a lot of careful and complex design in the
FireBase system. And it wasn't even possible to implement quotas the last I
checked (couple of months back).

------
groundCode
Given that the use case for Firebase is taking the place of your traditional
server side architecture and storage, it seems kind of obvious that you would
have to take heed of the security implications and set them up properly. The
security concerns don't magically vanish just because you don't write the
server side code.

~~~
manojlds
Actually, people might be of the wrong notion that doing things like

    
    
        if(!user) { alert('you are not logged in!');} 
    

are enough even when coding on the client side.

------
caffeineninja
This person obfuscates the emails poorly in the screenshots. Some of them are
still very readable.

If only the NSA used this level of blurring in their recent redacted
documents...

------
Kiro
Requiring Security Rules is a bad idea and would really stall the work flow in
projects where you don't need them. I have one of those where I don't care if
people manipulate the data via the console.

Anyway, the Firebase team should really address these security issues that
keep coming up all the time.

~~~
icebraining
They could just have an "ALLOW ALL" rule; at least, it would be an explicit
decision.

------
pewallin
Basically by disallowing read access to /users in the Firebase security rules
(which you should do), the latter 50% of the article would be moot. However
the html injection is interesting, be extra careful to validate data when
using dynamic jquery-selectors?

------
film42
This was something that really prevented me from pursuing Firebase as a real
asset, despite its easy real time socket magic. If there's a diagram to "roll
your own" after, though, it's probably moot (forums/ chat). Their json-rpc
server has a really slick api and they've spent a lot of time on problems such
as authentication and data security.

You could argue that moot is just a very well designed Firebase app as far as
security permissions go, but at least it's proof that it's possible to rely
entirely on pub/sub for your app and be fast, scalable, and successful.

~~~
film42
UPDATE: I seem to have been voted down. Yet, I have no idea why. Thanks, HN.

------
schrijver
Centralised data-stores for user data, didn’t recent developments remind why
that’s not a good idea?

------
Goranek
Nice DWM setup :)

~~~
xsb
It's not dwm, it looks like i3 [http://i3wm.org](http://i3wm.org)

~~~
Goranek
yeah it appears so. It looks really nice :)

