Is it safe to expose Firebase apiKey to the public?












282















The firebase Web-App guide states i should put the given apiKey in my Html to initialize firebase:



// TODO: Replace with your project's customized code snippet
<script src="https://www.gstatic.com/firebasejs/3.0.2/firebase.js"></script>
<script>
// Initialize Firebase
var config = {
apiKey: '<your-api-key>',
authDomain: '<your-auth-domain>',
databaseURL: '<your-database-url>',
storageBucket: '<your-storage-bucket>'
};
firebase.initializeApp(config);
</script>


By doing so the apiKey is exposed to every visitor. What is the purpose of that key and is it really meant to be public?










share|improve this question

























  • I think as long as you setup Firebase Auth and Firebase database rules you can give that info publicly.

    – jmb-mage
    Mar 12 at 16:39
















282















The firebase Web-App guide states i should put the given apiKey in my Html to initialize firebase:



// TODO: Replace with your project's customized code snippet
<script src="https://www.gstatic.com/firebasejs/3.0.2/firebase.js"></script>
<script>
// Initialize Firebase
var config = {
apiKey: '<your-api-key>',
authDomain: '<your-auth-domain>',
databaseURL: '<your-database-url>',
storageBucket: '<your-storage-bucket>'
};
firebase.initializeApp(config);
</script>


By doing so the apiKey is exposed to every visitor. What is the purpose of that key and is it really meant to be public?










share|improve this question

























  • I think as long as you setup Firebase Auth and Firebase database rules you can give that info publicly.

    – jmb-mage
    Mar 12 at 16:39














282












282








282


75






The firebase Web-App guide states i should put the given apiKey in my Html to initialize firebase:



// TODO: Replace with your project's customized code snippet
<script src="https://www.gstatic.com/firebasejs/3.0.2/firebase.js"></script>
<script>
// Initialize Firebase
var config = {
apiKey: '<your-api-key>',
authDomain: '<your-auth-domain>',
databaseURL: '<your-database-url>',
storageBucket: '<your-storage-bucket>'
};
firebase.initializeApp(config);
</script>


By doing so the apiKey is exposed to every visitor. What is the purpose of that key and is it really meant to be public?










share|improve this question
















The firebase Web-App guide states i should put the given apiKey in my Html to initialize firebase:



// TODO: Replace with your project's customized code snippet
<script src="https://www.gstatic.com/firebasejs/3.0.2/firebase.js"></script>
<script>
// Initialize Firebase
var config = {
apiKey: '<your-api-key>',
authDomain: '<your-auth-domain>',
databaseURL: '<your-database-url>',
storageBucket: '<your-storage-bucket>'
};
firebase.initializeApp(config);
</script>


By doing so the apiKey is exposed to every visitor. What is the purpose of that key and is it really meant to be public?







javascript firebase






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jul 15 '18 at 14:03









Frank van Puffelen

243k29387414




243k29387414










asked May 27 '16 at 11:30









farmiofarmio

2,2472916




2,2472916













  • I think as long as you setup Firebase Auth and Firebase database rules you can give that info publicly.

    – jmb-mage
    Mar 12 at 16:39



















  • I think as long as you setup Firebase Auth and Firebase database rules you can give that info publicly.

    – jmb-mage
    Mar 12 at 16:39

















I think as long as you setup Firebase Auth and Firebase database rules you can give that info publicly.

– jmb-mage
Mar 12 at 16:39





I think as long as you setup Firebase Auth and Firebase database rules you can give that info publicly.

– jmb-mage
Mar 12 at 16:39












3 Answers
3






active

oldest

votes


















272














The apiKey essentially just identifies your Firebase project on the Google servers. It is not a security risk for someone to know it. In fact, it is necessary for them to know it, in order for them to interact with your Firebase project.



In that sense it is very similar to the database URL that Firebase has historically been used to identify the back-end: https://<app-id>.firebaseio.com. See this question on why this is not a security risk: How to restrict Firebase data modification?, including the use of Firebase's server side security rules to ensure only authorized users can access the backend services.






share|improve this answer





















  • 5





    So it means that other people would be able to access all the data in my firebase database?

    – Emmanuel Campos
    Jun 12 '16 at 14:30






  • 19





    @EmmanuelCampos Answer is Yes and No. Yes, if you allow or want the other people to access all the data in the database. And No, if you don't want them to. Firebase database has rules, rules that you control

    – Rexford
    Jun 12 '16 at 15:40






  • 4





    Found my answer here for my last question support.google.com/firebase/answer/6400741 Thanks for the help. This link may help someone in the future.

    – Emmanuel Campos
    Jun 13 '16 at 3:40






  • 6





    @m.rufca , your data should be available for users, who are authenticated. And here is the trick. By default, in your firebase settings only localhost and your project domains are authorized to perform authentication from them. So nobody else can create app which will normally work with your firebase.

    – Artem Arkhipov
    Feb 13 '17 at 8:13








  • 11





    what if bot is creating unlimited users at my app. How can I require captcha.

    – Muhammad Umer
    Mar 15 '17 at 2:45



















48














Building on the answers of prufrofro and Frank van Puffelen here, I put together this solution that doesn't prevent scraping, but can make it harder to use your API key.



Warning: To get your data, even with this method, one can for example simply open the JS console in Chrome and type:



firebase.database().ref("/get/all/the/data").once("value", function (data) {
console.log(data.val());
});


Only the database security rules can protect your data.



Nevertheless, I restricted my production API key use to my domain name like this:




  1. https://console.developers.google.com/apis

  2. Select your Firebase project


  3. Credentials

  4. Under API keys, pick your Browser key. It should look like this: "Browser key (auto created by Google Service)"

  5. In "Accept requests from these
    HTTP referrers (web sites)
    ", add the URL of your app (exemple: projectname.firebaseapp.com/* )


Now the app will only work on this domain name. So I created another API Key that will be private for localhost developement.




  1. Click Create credentials > API Key


This one is not restricted, so make sure you keep it private.



I use Webpack to build my production app. In order to make sure I don't publish this new unrestricted API key by mistake, I put it inside my index.html just as you would normally do with your API key. Then, inside my webpack.production.config.js file, I replace the key every time index.html is copied to the production build, like this:



plugins: [
new CopyWebpackPlugin([
{
transform: function(content, path) {
return content.toString().replace("###dev-key###", "###public-key###");
},
from: './index.html'
}
])
]


By default, as mentioned by Emmanuel Campos, Firebase only whitelists localhost and your Firebase hosting domain.






share|improve this answer


























  • Is that working fine for you? Was thinking to do the same thing for an Android app. I wonder why Firebase doesn't cover that in the security section.

    – MScott
    Jun 28 '17 at 1:19






  • 2





    I've had no problem so far, but probably no attacks either

    – now
    Jun 28 '17 at 19:05






  • 2





    This is not mentioned in their guide because it won't protect you from scraping. All this ensures is someone else can not make a web app that uses your firebase to read (or write) data, if it's run in a normal well behaved browser.

    – thoutbeckers
    Jul 4 '17 at 11:56






  • 2





    This was exactly the code snippet that I've been looking for!!! THANKS!

    – sonar
    Sep 28 '18 at 16:34








  • 1





    This is it! The absolute solution to go for.

    – Yoraco Gonzales
    Nov 8 '18 at 7:06



















12














I am not convinced to expose security/config keys to client. I would not call it secure, not because some one can steal all private information from first day, because someone can make excessive request, and drain your quota and make you owe to Google a lot of money.



You need to think about many concepts from restricting people not to access where they are not supposed to be, DOS attacks etc.



I would more prefer the client first will hit to your web server, there you put what ever first hand firewall, captcha , cloudflare, custom security in between the client and server, or between server and firebase and you are good to go. At least you can first stop suspect activity before it reaches to firebase. You will have much more flexibility.



I only see one good usage scenario for using client based config for internal usages. For example, you have internal domain, and you are pretty sure outsiders cannot access there, so you can setup environment like browser -> firebase type.






share|improve this answer



















  • 1





    But isn't it the same as "exposing" any other REST API? I mean with REST API URL are available to user. They can use the URL to make any requests they want and drain your quota. What firebase do is using config with api keys to identify your part of backend and it is and it has to be available for user to make requests.

    – mbochynski
    Jun 5 '18 at 6:37






  • 2





    @mbochynski but you can somewhat make direct requests to resources that cause you pay bill. And at Firebase side there are not that much control mechanism to prevent DDoS attacks etc. My suggestion would be that let your client call your REST API, but that REST API should hold API Keys privately, and even before you hit Firebase resources, validate them if they are legit requests. (via Cloudflare etc). or retrieve results from cache. Then you will only hit your Firebase resources only if you will need to. This is what I would implement firebase.google.com/docs/admin/setup

    – Teoman shipahi
    Jun 5 '18 at 14:01













Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f37482366%2fis-it-safe-to-expose-firebase-apikey-to-the-public%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























3 Answers
3






active

oldest

votes








3 Answers
3






active

oldest

votes









active

oldest

votes






active

oldest

votes









272














The apiKey essentially just identifies your Firebase project on the Google servers. It is not a security risk for someone to know it. In fact, it is necessary for them to know it, in order for them to interact with your Firebase project.



In that sense it is very similar to the database URL that Firebase has historically been used to identify the back-end: https://<app-id>.firebaseio.com. See this question on why this is not a security risk: How to restrict Firebase data modification?, including the use of Firebase's server side security rules to ensure only authorized users can access the backend services.






share|improve this answer





















  • 5





    So it means that other people would be able to access all the data in my firebase database?

    – Emmanuel Campos
    Jun 12 '16 at 14:30






  • 19





    @EmmanuelCampos Answer is Yes and No. Yes, if you allow or want the other people to access all the data in the database. And No, if you don't want them to. Firebase database has rules, rules that you control

    – Rexford
    Jun 12 '16 at 15:40






  • 4





    Found my answer here for my last question support.google.com/firebase/answer/6400741 Thanks for the help. This link may help someone in the future.

    – Emmanuel Campos
    Jun 13 '16 at 3:40






  • 6





    @m.rufca , your data should be available for users, who are authenticated. And here is the trick. By default, in your firebase settings only localhost and your project domains are authorized to perform authentication from them. So nobody else can create app which will normally work with your firebase.

    – Artem Arkhipov
    Feb 13 '17 at 8:13








  • 11





    what if bot is creating unlimited users at my app. How can I require captcha.

    – Muhammad Umer
    Mar 15 '17 at 2:45
















272














The apiKey essentially just identifies your Firebase project on the Google servers. It is not a security risk for someone to know it. In fact, it is necessary for them to know it, in order for them to interact with your Firebase project.



In that sense it is very similar to the database URL that Firebase has historically been used to identify the back-end: https://<app-id>.firebaseio.com. See this question on why this is not a security risk: How to restrict Firebase data modification?, including the use of Firebase's server side security rules to ensure only authorized users can access the backend services.






share|improve this answer





















  • 5





    So it means that other people would be able to access all the data in my firebase database?

    – Emmanuel Campos
    Jun 12 '16 at 14:30






  • 19





    @EmmanuelCampos Answer is Yes and No. Yes, if you allow or want the other people to access all the data in the database. And No, if you don't want them to. Firebase database has rules, rules that you control

    – Rexford
    Jun 12 '16 at 15:40






  • 4





    Found my answer here for my last question support.google.com/firebase/answer/6400741 Thanks for the help. This link may help someone in the future.

    – Emmanuel Campos
    Jun 13 '16 at 3:40






  • 6





    @m.rufca , your data should be available for users, who are authenticated. And here is the trick. By default, in your firebase settings only localhost and your project domains are authorized to perform authentication from them. So nobody else can create app which will normally work with your firebase.

    – Artem Arkhipov
    Feb 13 '17 at 8:13








  • 11





    what if bot is creating unlimited users at my app. How can I require captcha.

    – Muhammad Umer
    Mar 15 '17 at 2:45














272












272








272







The apiKey essentially just identifies your Firebase project on the Google servers. It is not a security risk for someone to know it. In fact, it is necessary for them to know it, in order for them to interact with your Firebase project.



In that sense it is very similar to the database URL that Firebase has historically been used to identify the back-end: https://<app-id>.firebaseio.com. See this question on why this is not a security risk: How to restrict Firebase data modification?, including the use of Firebase's server side security rules to ensure only authorized users can access the backend services.






share|improve this answer















The apiKey essentially just identifies your Firebase project on the Google servers. It is not a security risk for someone to know it. In fact, it is necessary for them to know it, in order for them to interact with your Firebase project.



In that sense it is very similar to the database URL that Firebase has historically been used to identify the back-end: https://<app-id>.firebaseio.com. See this question on why this is not a security risk: How to restrict Firebase data modification?, including the use of Firebase's server side security rules to ensure only authorized users can access the backend services.







share|improve this answer














share|improve this answer



share|improve this answer








edited Dec 9 '17 at 20:50

























answered May 27 '16 at 12:51









Frank van PuffelenFrank van Puffelen

243k29387414




243k29387414








  • 5





    So it means that other people would be able to access all the data in my firebase database?

    – Emmanuel Campos
    Jun 12 '16 at 14:30






  • 19





    @EmmanuelCampos Answer is Yes and No. Yes, if you allow or want the other people to access all the data in the database. And No, if you don't want them to. Firebase database has rules, rules that you control

    – Rexford
    Jun 12 '16 at 15:40






  • 4





    Found my answer here for my last question support.google.com/firebase/answer/6400741 Thanks for the help. This link may help someone in the future.

    – Emmanuel Campos
    Jun 13 '16 at 3:40






  • 6





    @m.rufca , your data should be available for users, who are authenticated. And here is the trick. By default, in your firebase settings only localhost and your project domains are authorized to perform authentication from them. So nobody else can create app which will normally work with your firebase.

    – Artem Arkhipov
    Feb 13 '17 at 8:13








  • 11





    what if bot is creating unlimited users at my app. How can I require captcha.

    – Muhammad Umer
    Mar 15 '17 at 2:45














  • 5





    So it means that other people would be able to access all the data in my firebase database?

    – Emmanuel Campos
    Jun 12 '16 at 14:30






  • 19





    @EmmanuelCampos Answer is Yes and No. Yes, if you allow or want the other people to access all the data in the database. And No, if you don't want them to. Firebase database has rules, rules that you control

    – Rexford
    Jun 12 '16 at 15:40






  • 4





    Found my answer here for my last question support.google.com/firebase/answer/6400741 Thanks for the help. This link may help someone in the future.

    – Emmanuel Campos
    Jun 13 '16 at 3:40






  • 6





    @m.rufca , your data should be available for users, who are authenticated. And here is the trick. By default, in your firebase settings only localhost and your project domains are authorized to perform authentication from them. So nobody else can create app which will normally work with your firebase.

    – Artem Arkhipov
    Feb 13 '17 at 8:13








  • 11





    what if bot is creating unlimited users at my app. How can I require captcha.

    – Muhammad Umer
    Mar 15 '17 at 2:45








5




5





So it means that other people would be able to access all the data in my firebase database?

– Emmanuel Campos
Jun 12 '16 at 14:30





So it means that other people would be able to access all the data in my firebase database?

– Emmanuel Campos
Jun 12 '16 at 14:30




19




19





@EmmanuelCampos Answer is Yes and No. Yes, if you allow or want the other people to access all the data in the database. And No, if you don't want them to. Firebase database has rules, rules that you control

– Rexford
Jun 12 '16 at 15:40





@EmmanuelCampos Answer is Yes and No. Yes, if you allow or want the other people to access all the data in the database. And No, if you don't want them to. Firebase database has rules, rules that you control

– Rexford
Jun 12 '16 at 15:40




4




4





Found my answer here for my last question support.google.com/firebase/answer/6400741 Thanks for the help. This link may help someone in the future.

– Emmanuel Campos
Jun 13 '16 at 3:40





Found my answer here for my last question support.google.com/firebase/answer/6400741 Thanks for the help. This link may help someone in the future.

– Emmanuel Campos
Jun 13 '16 at 3:40




6




6





@m.rufca , your data should be available for users, who are authenticated. And here is the trick. By default, in your firebase settings only localhost and your project domains are authorized to perform authentication from them. So nobody else can create app which will normally work with your firebase.

– Artem Arkhipov
Feb 13 '17 at 8:13







@m.rufca , your data should be available for users, who are authenticated. And here is the trick. By default, in your firebase settings only localhost and your project domains are authorized to perform authentication from them. So nobody else can create app which will normally work with your firebase.

– Artem Arkhipov
Feb 13 '17 at 8:13






11




11





what if bot is creating unlimited users at my app. How can I require captcha.

– Muhammad Umer
Mar 15 '17 at 2:45





what if bot is creating unlimited users at my app. How can I require captcha.

– Muhammad Umer
Mar 15 '17 at 2:45













48














Building on the answers of prufrofro and Frank van Puffelen here, I put together this solution that doesn't prevent scraping, but can make it harder to use your API key.



Warning: To get your data, even with this method, one can for example simply open the JS console in Chrome and type:



firebase.database().ref("/get/all/the/data").once("value", function (data) {
console.log(data.val());
});


Only the database security rules can protect your data.



Nevertheless, I restricted my production API key use to my domain name like this:




  1. https://console.developers.google.com/apis

  2. Select your Firebase project


  3. Credentials

  4. Under API keys, pick your Browser key. It should look like this: "Browser key (auto created by Google Service)"

  5. In "Accept requests from these
    HTTP referrers (web sites)
    ", add the URL of your app (exemple: projectname.firebaseapp.com/* )


Now the app will only work on this domain name. So I created another API Key that will be private for localhost developement.




  1. Click Create credentials > API Key


This one is not restricted, so make sure you keep it private.



I use Webpack to build my production app. In order to make sure I don't publish this new unrestricted API key by mistake, I put it inside my index.html just as you would normally do with your API key. Then, inside my webpack.production.config.js file, I replace the key every time index.html is copied to the production build, like this:



plugins: [
new CopyWebpackPlugin([
{
transform: function(content, path) {
return content.toString().replace("###dev-key###", "###public-key###");
},
from: './index.html'
}
])
]


By default, as mentioned by Emmanuel Campos, Firebase only whitelists localhost and your Firebase hosting domain.






share|improve this answer


























  • Is that working fine for you? Was thinking to do the same thing for an Android app. I wonder why Firebase doesn't cover that in the security section.

    – MScott
    Jun 28 '17 at 1:19






  • 2





    I've had no problem so far, but probably no attacks either

    – now
    Jun 28 '17 at 19:05






  • 2





    This is not mentioned in their guide because it won't protect you from scraping. All this ensures is someone else can not make a web app that uses your firebase to read (or write) data, if it's run in a normal well behaved browser.

    – thoutbeckers
    Jul 4 '17 at 11:56






  • 2





    This was exactly the code snippet that I've been looking for!!! THANKS!

    – sonar
    Sep 28 '18 at 16:34








  • 1





    This is it! The absolute solution to go for.

    – Yoraco Gonzales
    Nov 8 '18 at 7:06
















48














Building on the answers of prufrofro and Frank van Puffelen here, I put together this solution that doesn't prevent scraping, but can make it harder to use your API key.



Warning: To get your data, even with this method, one can for example simply open the JS console in Chrome and type:



firebase.database().ref("/get/all/the/data").once("value", function (data) {
console.log(data.val());
});


Only the database security rules can protect your data.



Nevertheless, I restricted my production API key use to my domain name like this:




  1. https://console.developers.google.com/apis

  2. Select your Firebase project


  3. Credentials

  4. Under API keys, pick your Browser key. It should look like this: "Browser key (auto created by Google Service)"

  5. In "Accept requests from these
    HTTP referrers (web sites)
    ", add the URL of your app (exemple: projectname.firebaseapp.com/* )


Now the app will only work on this domain name. So I created another API Key that will be private for localhost developement.




  1. Click Create credentials > API Key


This one is not restricted, so make sure you keep it private.



I use Webpack to build my production app. In order to make sure I don't publish this new unrestricted API key by mistake, I put it inside my index.html just as you would normally do with your API key. Then, inside my webpack.production.config.js file, I replace the key every time index.html is copied to the production build, like this:



plugins: [
new CopyWebpackPlugin([
{
transform: function(content, path) {
return content.toString().replace("###dev-key###", "###public-key###");
},
from: './index.html'
}
])
]


By default, as mentioned by Emmanuel Campos, Firebase only whitelists localhost and your Firebase hosting domain.






share|improve this answer


























  • Is that working fine for you? Was thinking to do the same thing for an Android app. I wonder why Firebase doesn't cover that in the security section.

    – MScott
    Jun 28 '17 at 1:19






  • 2





    I've had no problem so far, but probably no attacks either

    – now
    Jun 28 '17 at 19:05






  • 2





    This is not mentioned in their guide because it won't protect you from scraping. All this ensures is someone else can not make a web app that uses your firebase to read (or write) data, if it's run in a normal well behaved browser.

    – thoutbeckers
    Jul 4 '17 at 11:56






  • 2





    This was exactly the code snippet that I've been looking for!!! THANKS!

    – sonar
    Sep 28 '18 at 16:34








  • 1





    This is it! The absolute solution to go for.

    – Yoraco Gonzales
    Nov 8 '18 at 7:06














48












48








48







Building on the answers of prufrofro and Frank van Puffelen here, I put together this solution that doesn't prevent scraping, but can make it harder to use your API key.



Warning: To get your data, even with this method, one can for example simply open the JS console in Chrome and type:



firebase.database().ref("/get/all/the/data").once("value", function (data) {
console.log(data.val());
});


Only the database security rules can protect your data.



Nevertheless, I restricted my production API key use to my domain name like this:




  1. https://console.developers.google.com/apis

  2. Select your Firebase project


  3. Credentials

  4. Under API keys, pick your Browser key. It should look like this: "Browser key (auto created by Google Service)"

  5. In "Accept requests from these
    HTTP referrers (web sites)
    ", add the URL of your app (exemple: projectname.firebaseapp.com/* )


Now the app will only work on this domain name. So I created another API Key that will be private for localhost developement.




  1. Click Create credentials > API Key


This one is not restricted, so make sure you keep it private.



I use Webpack to build my production app. In order to make sure I don't publish this new unrestricted API key by mistake, I put it inside my index.html just as you would normally do with your API key. Then, inside my webpack.production.config.js file, I replace the key every time index.html is copied to the production build, like this:



plugins: [
new CopyWebpackPlugin([
{
transform: function(content, path) {
return content.toString().replace("###dev-key###", "###public-key###");
},
from: './index.html'
}
])
]


By default, as mentioned by Emmanuel Campos, Firebase only whitelists localhost and your Firebase hosting domain.






share|improve this answer















Building on the answers of prufrofro and Frank van Puffelen here, I put together this solution that doesn't prevent scraping, but can make it harder to use your API key.



Warning: To get your data, even with this method, one can for example simply open the JS console in Chrome and type:



firebase.database().ref("/get/all/the/data").once("value", function (data) {
console.log(data.val());
});


Only the database security rules can protect your data.



Nevertheless, I restricted my production API key use to my domain name like this:




  1. https://console.developers.google.com/apis

  2. Select your Firebase project


  3. Credentials

  4. Under API keys, pick your Browser key. It should look like this: "Browser key (auto created by Google Service)"

  5. In "Accept requests from these
    HTTP referrers (web sites)
    ", add the URL of your app (exemple: projectname.firebaseapp.com/* )


Now the app will only work on this domain name. So I created another API Key that will be private for localhost developement.




  1. Click Create credentials > API Key


This one is not restricted, so make sure you keep it private.



I use Webpack to build my production app. In order to make sure I don't publish this new unrestricted API key by mistake, I put it inside my index.html just as you would normally do with your API key. Then, inside my webpack.production.config.js file, I replace the key every time index.html is copied to the production build, like this:



plugins: [
new CopyWebpackPlugin([
{
transform: function(content, path) {
return content.toString().replace("###dev-key###", "###public-key###");
},
from: './index.html'
}
])
]


By default, as mentioned by Emmanuel Campos, Firebase only whitelists localhost and your Firebase hosting domain.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 25 '17 at 0:49

























answered Dec 4 '16 at 18:40









nownow

2,32111618




2,32111618













  • Is that working fine for you? Was thinking to do the same thing for an Android app. I wonder why Firebase doesn't cover that in the security section.

    – MScott
    Jun 28 '17 at 1:19






  • 2





    I've had no problem so far, but probably no attacks either

    – now
    Jun 28 '17 at 19:05






  • 2





    This is not mentioned in their guide because it won't protect you from scraping. All this ensures is someone else can not make a web app that uses your firebase to read (or write) data, if it's run in a normal well behaved browser.

    – thoutbeckers
    Jul 4 '17 at 11:56






  • 2





    This was exactly the code snippet that I've been looking for!!! THANKS!

    – sonar
    Sep 28 '18 at 16:34








  • 1





    This is it! The absolute solution to go for.

    – Yoraco Gonzales
    Nov 8 '18 at 7:06



















  • Is that working fine for you? Was thinking to do the same thing for an Android app. I wonder why Firebase doesn't cover that in the security section.

    – MScott
    Jun 28 '17 at 1:19






  • 2





    I've had no problem so far, but probably no attacks either

    – now
    Jun 28 '17 at 19:05






  • 2





    This is not mentioned in their guide because it won't protect you from scraping. All this ensures is someone else can not make a web app that uses your firebase to read (or write) data, if it's run in a normal well behaved browser.

    – thoutbeckers
    Jul 4 '17 at 11:56






  • 2





    This was exactly the code snippet that I've been looking for!!! THANKS!

    – sonar
    Sep 28 '18 at 16:34








  • 1





    This is it! The absolute solution to go for.

    – Yoraco Gonzales
    Nov 8 '18 at 7:06

















Is that working fine for you? Was thinking to do the same thing for an Android app. I wonder why Firebase doesn't cover that in the security section.

– MScott
Jun 28 '17 at 1:19





Is that working fine for you? Was thinking to do the same thing for an Android app. I wonder why Firebase doesn't cover that in the security section.

– MScott
Jun 28 '17 at 1:19




2




2





I've had no problem so far, but probably no attacks either

– now
Jun 28 '17 at 19:05





I've had no problem so far, but probably no attacks either

– now
Jun 28 '17 at 19:05




2




2





This is not mentioned in their guide because it won't protect you from scraping. All this ensures is someone else can not make a web app that uses your firebase to read (or write) data, if it's run in a normal well behaved browser.

– thoutbeckers
Jul 4 '17 at 11:56





This is not mentioned in their guide because it won't protect you from scraping. All this ensures is someone else can not make a web app that uses your firebase to read (or write) data, if it's run in a normal well behaved browser.

– thoutbeckers
Jul 4 '17 at 11:56




2




2





This was exactly the code snippet that I've been looking for!!! THANKS!

– sonar
Sep 28 '18 at 16:34







This was exactly the code snippet that I've been looking for!!! THANKS!

– sonar
Sep 28 '18 at 16:34






1




1





This is it! The absolute solution to go for.

– Yoraco Gonzales
Nov 8 '18 at 7:06





This is it! The absolute solution to go for.

– Yoraco Gonzales
Nov 8 '18 at 7:06











12














I am not convinced to expose security/config keys to client. I would not call it secure, not because some one can steal all private information from first day, because someone can make excessive request, and drain your quota and make you owe to Google a lot of money.



You need to think about many concepts from restricting people not to access where they are not supposed to be, DOS attacks etc.



I would more prefer the client first will hit to your web server, there you put what ever first hand firewall, captcha , cloudflare, custom security in between the client and server, or between server and firebase and you are good to go. At least you can first stop suspect activity before it reaches to firebase. You will have much more flexibility.



I only see one good usage scenario for using client based config for internal usages. For example, you have internal domain, and you are pretty sure outsiders cannot access there, so you can setup environment like browser -> firebase type.






share|improve this answer



















  • 1





    But isn't it the same as "exposing" any other REST API? I mean with REST API URL are available to user. They can use the URL to make any requests they want and drain your quota. What firebase do is using config with api keys to identify your part of backend and it is and it has to be available for user to make requests.

    – mbochynski
    Jun 5 '18 at 6:37






  • 2





    @mbochynski but you can somewhat make direct requests to resources that cause you pay bill. And at Firebase side there are not that much control mechanism to prevent DDoS attacks etc. My suggestion would be that let your client call your REST API, but that REST API should hold API Keys privately, and even before you hit Firebase resources, validate them if they are legit requests. (via Cloudflare etc). or retrieve results from cache. Then you will only hit your Firebase resources only if you will need to. This is what I would implement firebase.google.com/docs/admin/setup

    – Teoman shipahi
    Jun 5 '18 at 14:01


















12














I am not convinced to expose security/config keys to client. I would not call it secure, not because some one can steal all private information from first day, because someone can make excessive request, and drain your quota and make you owe to Google a lot of money.



You need to think about many concepts from restricting people not to access where they are not supposed to be, DOS attacks etc.



I would more prefer the client first will hit to your web server, there you put what ever first hand firewall, captcha , cloudflare, custom security in between the client and server, or between server and firebase and you are good to go. At least you can first stop suspect activity before it reaches to firebase. You will have much more flexibility.



I only see one good usage scenario for using client based config for internal usages. For example, you have internal domain, and you are pretty sure outsiders cannot access there, so you can setup environment like browser -> firebase type.






share|improve this answer



















  • 1





    But isn't it the same as "exposing" any other REST API? I mean with REST API URL are available to user. They can use the URL to make any requests they want and drain your quota. What firebase do is using config with api keys to identify your part of backend and it is and it has to be available for user to make requests.

    – mbochynski
    Jun 5 '18 at 6:37






  • 2





    @mbochynski but you can somewhat make direct requests to resources that cause you pay bill. And at Firebase side there are not that much control mechanism to prevent DDoS attacks etc. My suggestion would be that let your client call your REST API, but that REST API should hold API Keys privately, and even before you hit Firebase resources, validate them if they are legit requests. (via Cloudflare etc). or retrieve results from cache. Then you will only hit your Firebase resources only if you will need to. This is what I would implement firebase.google.com/docs/admin/setup

    – Teoman shipahi
    Jun 5 '18 at 14:01
















12












12








12







I am not convinced to expose security/config keys to client. I would not call it secure, not because some one can steal all private information from first day, because someone can make excessive request, and drain your quota and make you owe to Google a lot of money.



You need to think about many concepts from restricting people not to access where they are not supposed to be, DOS attacks etc.



I would more prefer the client first will hit to your web server, there you put what ever first hand firewall, captcha , cloudflare, custom security in between the client and server, or between server and firebase and you are good to go. At least you can first stop suspect activity before it reaches to firebase. You will have much more flexibility.



I only see one good usage scenario for using client based config for internal usages. For example, you have internal domain, and you are pretty sure outsiders cannot access there, so you can setup environment like browser -> firebase type.






share|improve this answer













I am not convinced to expose security/config keys to client. I would not call it secure, not because some one can steal all private information from first day, because someone can make excessive request, and drain your quota and make you owe to Google a lot of money.



You need to think about many concepts from restricting people not to access where they are not supposed to be, DOS attacks etc.



I would more prefer the client first will hit to your web server, there you put what ever first hand firewall, captcha , cloudflare, custom security in between the client and server, or between server and firebase and you are good to go. At least you can first stop suspect activity before it reaches to firebase. You will have much more flexibility.



I only see one good usage scenario for using client based config for internal usages. For example, you have internal domain, and you are pretty sure outsiders cannot access there, so you can setup environment like browser -> firebase type.







share|improve this answer












share|improve this answer



share|improve this answer










answered Oct 23 '17 at 4:06









Teoman shipahiTeoman shipahi

35.8k88296




35.8k88296








  • 1





    But isn't it the same as "exposing" any other REST API? I mean with REST API URL are available to user. They can use the URL to make any requests they want and drain your quota. What firebase do is using config with api keys to identify your part of backend and it is and it has to be available for user to make requests.

    – mbochynski
    Jun 5 '18 at 6:37






  • 2





    @mbochynski but you can somewhat make direct requests to resources that cause you pay bill. And at Firebase side there are not that much control mechanism to prevent DDoS attacks etc. My suggestion would be that let your client call your REST API, but that REST API should hold API Keys privately, and even before you hit Firebase resources, validate them if they are legit requests. (via Cloudflare etc). or retrieve results from cache. Then you will only hit your Firebase resources only if you will need to. This is what I would implement firebase.google.com/docs/admin/setup

    – Teoman shipahi
    Jun 5 '18 at 14:01
















  • 1





    But isn't it the same as "exposing" any other REST API? I mean with REST API URL are available to user. They can use the URL to make any requests they want and drain your quota. What firebase do is using config with api keys to identify your part of backend and it is and it has to be available for user to make requests.

    – mbochynski
    Jun 5 '18 at 6:37






  • 2





    @mbochynski but you can somewhat make direct requests to resources that cause you pay bill. And at Firebase side there are not that much control mechanism to prevent DDoS attacks etc. My suggestion would be that let your client call your REST API, but that REST API should hold API Keys privately, and even before you hit Firebase resources, validate them if they are legit requests. (via Cloudflare etc). or retrieve results from cache. Then you will only hit your Firebase resources only if you will need to. This is what I would implement firebase.google.com/docs/admin/setup

    – Teoman shipahi
    Jun 5 '18 at 14:01










1




1





But isn't it the same as "exposing" any other REST API? I mean with REST API URL are available to user. They can use the URL to make any requests they want and drain your quota. What firebase do is using config with api keys to identify your part of backend and it is and it has to be available for user to make requests.

– mbochynski
Jun 5 '18 at 6:37





But isn't it the same as "exposing" any other REST API? I mean with REST API URL are available to user. They can use the URL to make any requests they want and drain your quota. What firebase do is using config with api keys to identify your part of backend and it is and it has to be available for user to make requests.

– mbochynski
Jun 5 '18 at 6:37




2




2





@mbochynski but you can somewhat make direct requests to resources that cause you pay bill. And at Firebase side there are not that much control mechanism to prevent DDoS attacks etc. My suggestion would be that let your client call your REST API, but that REST API should hold API Keys privately, and even before you hit Firebase resources, validate them if they are legit requests. (via Cloudflare etc). or retrieve results from cache. Then you will only hit your Firebase resources only if you will need to. This is what I would implement firebase.google.com/docs/admin/setup

– Teoman shipahi
Jun 5 '18 at 14:01







@mbochynski but you can somewhat make direct requests to resources that cause you pay bill. And at Firebase side there are not that much control mechanism to prevent DDoS attacks etc. My suggestion would be that let your client call your REST API, but that REST API should hold API Keys privately, and even before you hit Firebase resources, validate them if they are legit requests. (via Cloudflare etc). or retrieve results from cache. Then you will only hit your Firebase resources only if you will need to. This is what I would implement firebase.google.com/docs/admin/setup

– Teoman shipahi
Jun 5 '18 at 14:01




















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f37482366%2fis-it-safe-to-expose-firebase-apikey-to-the-public%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

MongoDB - Not Authorized To Execute Command

How to fix TextFormField cause rebuild widget in Flutter

in spring boot 2.1 many test slices are not allowed anymore due to multiple @BootstrapWith