Where to store secret keys when using Polymer + Firebase?

Question

I'm developing a web application using Polymer + Firebase. In my app, I'm trying to integrate it to Slack. In order to obtain an access token from Slack, I need to make an api call to Slack with the client secret key (generated by Slack).

The question is, where/how should I store this client secret key? Hardcoding this key in my Polymer app sure sounds like a big security no no.

Thanks.

Answer 1

Use Environment Variables for Firebase secrets

To set your environment variables, create a functions/.env file of the format ...

ACCOUNT=xxxx
API_KEY=yyyy

You can override these variable for specific project aliases. So if for example you'd aliased your project deployment instances as dev, stage, prod ... you can override the settings in your .env file with similar files named as .env.dev, .env.stage or .env.prod.

Then in local emulator or deployed code you can use:

const functions = require('firebase-functions');
const apikey = process.env.API_KEY;
const url = `https://hooks.slack.com/services/${apikey}`
// call Slack API

For full details refer to

• https://firebase.google.com/docs/functions/config-env

Don't use remote config for secrets!!

The Firebase documentation is (or was) rather vague about whether remote config was intended for use as a secure store. It should however NOT be used for storing secrets since it's designed to be accessible and used on both client and server.

At time of writing, the Firebase document did not make this security issue clear. So Firebase team ... please add a security warning at the top of the documentation for Remote Config. I know this has tripped up many Firebase developers who've assumed that "configuration" meant "secure configuration".

Answer 2

Storing a secret in your client-side code sounds like a very bad idea. Any malicious user can get it there.

Any other way that requires access to the secret on the client is similarly flawed.

The only solution is one that doesn't require the secret to exist on the client, so one that involves running code in a trusted location. Typically this will be a server, but don't overestimate how much hardware you need to run such code on. Requiring a server in this case is about trust, not about bigger hardware.

See pattern 2 in this article about common application architectures on Firebase.