entityMap|blocks|key|8254j|text|基于prufrofro和Frank+van+Puffelen在这里的回答，我将这个设置组合在一起，它不会阻止抓取，但会使使用API密钥变得稍微困难一些。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2m36q|警告:要获取您的数据，即使使用此方法，也可以简单地在Chrome中打开JS控制台并输入：|b2c2o|只有数据库安全规则才能保护您的数据。|fb7l9|然而，我将生产API密钥的使用限制在我的域名上，如下所示：|12erh|https://console.developers.google.com/apis|b4niv|选择您的Firebase项目|98vn9|凭据|2gu6l|在API密钥下，选择您的浏览器密钥。它应该看起来像这样："Browser+key+(由Google+Service自动创建)“|c5o93|在“接受来自这些超文本传输协议推荐者(网站)的请求”中，添加应用程序的网址(例如：projectname.firebaseapp.com/*+)|offset|length|style|CODE|20tu|现在，该应用程序将只在这个特定的域名上工作。因此，我创建了另一个API密钥，它将是本地主机开发的私有密钥。|2nc4|单击创建凭据>+API密钥|34o2r|默认情况下，正如Emmanuel+Campos所提到的，Firebase只将localhost和您的Firebase托管域列入白名单。|9n0u8|为了确保我不会错误地发布错误的API密钥，我使用以下方法之一在生产中自动使用更受限制的API密钥。|5qc8i|Create-React-App的设置|2290m|在/env.development中|7avm1|在/env.production中|en2hl|在/src/index.js中^0|0|0|0|0|0|0|0|0|15|T|0|0|0|12|9|0|0|0|1|G|0|1|F|0|1|D^^$0|$]|1|@$2|3|4|5|6|7|8|1C|9|@]|A|@]|B|$]]|$2|C|4|D|6|7|8|1D|9|@]|A|@]|B|$]]|$2|E|4|F|6|7|8|1E|9|@]|A|@]|B|$]]|$2|G|4|H|6|7|8|1F|9|@]|A|@]|B|$]]|$2|I|4|J|6|7|8|1G|9|@]|A|@]|B|$]]|$2|K|4|L|6|7|8|1H|9|@]|A|@]|B|$]]|$2|M|4|N|6|7|8|1I|9|@]|A|@]|B|$]]|$2|O|4|P|6|7|8|1J|9|@]|A|@]|B|$]]|$2|Q|4|R|6|7|8|1K|9|@$S|1L|T|1M|U|V]]|A|@]|B|$]]|$2|W|4|X|6|7|8|1N|9|@]|A|@]|B|$]]|$2|Y|4|Z|6|7|8|1O|9|@]|A|@]|B|$]]|$2|10|4|11|6|7|8|1P|9|@$S|1Q|T|1R|U|V]]|A|@]|B|$]]|$2|12|4|13|6|7|8|1S|9|@]|A|@]|B|$]]|$2|14|4|15|6|7|8|1T|9|@]|A|@]|B|$]]|$2|16|4|17|6|7|8|1U|9|@$S|1V|T|1W|U|V]]|A|@]|B|$]]|$2|18|4|19|6|7|8|1X|9|@$S|1Y|T|1Z|U|V]]|A|@]|B|$]]|$2|1A|4|1B|6|7|8|20|9|@$S|21|T|22|U|V]]|A|@]|B|$]]]]

Building on the answers of prufrofro and Frank van Puffelen <a href="https://stackoverflow.com/questions/35418143/how-to-restrict-firebase-data-modification">here</a>, I put together this setup that doesn't prevent scraping, but can make it slightly 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:
<pre><code>firebase.database().ref(&quot;/get/all/the/data&quot;).once(&quot;value&quot;, function (data) {
 console.log(data.val());
});
</code></pre>
Only the database security rules can protect your data.
Nevertheless, I restricted my production API key use to my domain name like this:
<ol>
<li><a href="https://console.developers.google.com/apis" rel="noreferrer">https://console.developers.google.com/apis</a></li>
<li>Select your Firebase project</li>
<li>Credentials</li>
<li>Under API keys, pick your Browser key. It should look like this: &quot;Browser key (auto created by Google Service)&quot;</li>
<li>In &quot;Accept requests from these
HTTP referrers (web sites)&quot;, add the URL of your app (exemple: <code>projectname.firebaseapp.com/*</code> )</li>
</ol>
Now the app will only work on this specific domain name. So I created another API Key that will be private for localhost developement.
<ol>
<li>Click Create credentials &gt; API Key</li>
</ol>
By default, as mentioned by Emmanuel Campos, <a href="https://support.google.com/firebase/answer/6400741" rel="noreferrer">Firebase only whitelists <code>localhost</code> and your Firebase hosting domain</a>.
<hr />
In order to make sure I don't publish the wrong API key by mistake, I use one of the following methods to automatically use the more restricted one in production.
Setup for Create-React-App
In <code>/env.development</code>:
<pre><code>REACT_APP_API_KEY=###dev-key###
</code></pre>
In <code>/env.production</code>:
<pre><code>REACT_APP_API_KEY=###public-key###
</code></pre>
In <code>/src/index.js</code>
<pre><code>const firebaseConfig = {
 apiKey: process.env.REACT_APP_API_KEY,
 // ... 
};
</code></pre>

entityMap|blocks|key|n908|text|我不相信向客户端公开安全/配置密钥。我不会说它是安全的，不是因为有人可以从第一天起就窃取所有的私人信息，因为有人可能会发出过多的请求，耗尽你的配额，让你欠谷歌一大笔钱。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|841bj|你需要考虑许多概念，从限制人们不能访问他们不应该访问的地方，DOS攻击等等。|3gd3m|我更希望客户端优先连接到您的web服务器，在那里您可以在客户端和服务器之间或服务器和firebase之间放置任何第一手防火墙、验证码、cloudflare、自定义安全，您就可以使用了。至少您可以在可疑活动到达firebase之前先阻止它。你会有更大的灵活性。|78u3p|我只看到一个很好的使用场景，那就是将基于客户端的配置用于内部使用。例如，您有内部域，并且您非常确定外部人员无法访问该域，因此您可以设置类似于浏览器->+firebase类型的环境。^0|0|0|0^^$0|$]|1|@$2|3|4|5|6|7|8|I|9|@]|A|@]|B|$]]|$2|C|4|D|6|7|8|J|9|@]|A|@]|B|$]]|$2|E|4|F|6|7|8|K|9|@]|A|@]|B|$]]|$2|G|4|H|6|7|8|L|9|@]|A|@]|B|$]]]]

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.

entityMap|blocks|key|4bc9t|text|当启用用户/密码注册时，API密钥暴露会创建一个漏洞。有一个开放的API端点，它接受API密钥并允许任何人创建新的用户帐户。然后，他们可以使用这个新帐户登录到受Firebase+Auth保护的应用程序，或者使用SDK通过user/pass进行身份验证并运行查询。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|fpfan|我已经向谷歌报告了这一点，但他们说这是预期的工作。|75hbs|如果您不能禁用用户/密码帐户，您应该执行以下操作:创建一个云函数来自动禁用新用户的onCreate，并创建一个新的DB条目来管理他们的访问。|ej32i|例如:+MyUsers/{userId}/Access:+0|2ulm5|将您的规则更新为仅允许访问权限大于1的用户读取。|inpb|如果侦听器功能禁用帐户的速度不够快，那么读取规则将阻止它们读取任何数据。^0|0|0|0|0|0^^$0|$]|1|@$2|3|4|5|6|7|8|M|9|@]|A|@]|B|$]]|$2|C|4|D|6|7|8|N|9|@]|A|@]|B|$]]|$2|E|4|F|6|7|8|O|9|@]|A|@]|B|$]]|$2|G|4|H|6|7|8|P|9|@]|A|@]|B|$]]|$2|I|4|J|6|7|8|Q|9|@]|A|@]|B|$]]|$2|K|4|L|6|7|8|R|9|@]|A|@]|B|$]]]]

The API key exposure creates a vulnerability when user/password sign up is enabled. There is an open API endpoint that takes the API key and allows anyone to create a new user account. They then can use this new account to log in to your Firebase Auth protected app or use the SDK to auth with user/pass and run queries.

I've reported this to Google but they say it's working as intended.

If you can't disable user/password accounts you should do the following:
Create a cloud function to auto disable new users onCreate and create a new DB entry to manage their access.

Ex: MyUsers/{userId}/Access: 0 

<pre><code>exports.addUser = functions.auth.user().onCreate(onAddUser);
exports.deleteUser = functions.auth.user().onDelete(onDeleteUser);
</code></pre>

Update your rules to only allow reads for users with access > 1.

On the off chance the listener function doesn't disable the account fast enough then the read rules will prevent them from reading any data.

entityMap|blocks|key|9h325|text|我相信一旦数据库规则被准确地写出来，就足以保护你的数据了。此外，有一些指导原则可以用来相应地构建您的数据库。例如，在users下创建一个UID节点，并将所有信息放在该节点下。之后，您将需要实现一个简单的数据库规则，如下所示|type|unstyled|depth|inlineStyleRanges|entityRanges|data|f6a4d|其他用户将无法读取其他用户的数据，而且域策略将限制来自其他域的请求。您可以在Firebase安全规则上阅读更多关于它的信息^0|0^^$0|$]|1|@$2|3|4|5|6|7|8|E|9|@]|A|@]|B|$]]|$2|C|4|D|6|7|8|F|9|@]|A|@]|B|$]]]]

I believe once database rules are written accurately, it will be enough to protect your data. Moreover, there are guidelines that one can follow to structure your database accordingly. For example, making a UID node under users, and putting all under information under it. After that, you will need to implement a simple database rule as below 

<pre><code> "rules": {
 "users": {
 "$uid": {
 ".read": "auth != null &amp;&amp; auth.uid == $uid",
 ".write": "auth != null &amp;&amp; auth.uid == $uid"
 }
 }
 }
}
</code></pre>

No other user will be able to read other users' data, moreover, domain policy will restrict requests coming from other domains. 
One can read more about it on 
<a href="https://firebase.google.com/docs/database/security/user-security" rel="noreferrer">Firebase Security rules</a>

entityMap|blocks|key|6f6a3|text|您不应公开此信息。在公共场合，特别是api密钥。这可能会导致隐私泄露。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|d8lgi|在公开网站之前，你应该把它隐藏起来。你可以用两种或更多的方式来完成|ffuu1|复杂的编码/隐藏|91bq4|只需将firebase+SDK代码放在您的网站或应用程序的底部，firebase就会自动完成所有工作。您不需要将API密钥放在任何地方^0|0|0|0^^$0|$]|1|@$2|3|4|5|6|7|8|I|9|@]|A|@]|B|$]]|$2|C|4|D|6|7|8|J|9|@]|A|@]|B|$]]|$2|E|4|F|6|7|8|K|9|@]|A|@]|B|$]]|$2|G|4|H|6|7|8|L|9|@]|A|@]|B|$]]]]

You should not expose this info. in public, specially api keys.
It may lead to a privacy leak.

Before making the website public you should hide it. You can do it in 2 or more ways

<ol>
<li>Complex coding/hiding</li>
<li>Simply put firebase SDK codes at bottom of your website or app thus firebase automatically does all works. you don't need to put API keys anywhere</li>
</ol>

entityMap|blocks|key|3g4k7|text|API密钥的暴露不是安全风险，但任何人都可以将您的凭据放到他们的网站上。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|d1lnt|开放api密钥会导致攻击，这些攻击会占用firebase的大量资源，这肯定会让您付出艰苦的代价。|86s8n|您可以始终限制您的firebase项目关键字到域/IP。|pubm|https://console.cloud.google.com/apis/credentials/key|fg3v4|选择您的项目Id和密钥，并将其限制为您的Android/iOs/web应用程序。^0|0|0|0|0^^$0|$]|1|@$2|3|4|5|6|7|8|K|9|@]|A|@]|B|$]]|$2|C|4|D|6|7|8|L|9|@]|A|@]|B|$]]|$2|E|4|F|6|7|8|M|9|@]|A|@]|B|$]]|$2|G|4|H|6|7|8|N|9|@]|A|@]|B|$]]|$2|I|4|J|6|7|8|O|9|@]|A|@]|B|$]]]]

EXPOSURE OF API KEYS ISN'T A SECURITY RISK BUT ANYONE CAN PUT YOUR CREDENTIALS ON THEIR SITE.
Open api keys leads to attacks that can use a lot resources at firebase that will definitely cost your hard money.
You can always restrict you firebase project keys to domains / IP's.
<a href="https://console.cloud.google.com/apis/credentials/key" rel="nofollow noreferrer">https://console.cloud.google.com/apis/credentials/key</a>
select your project Id and key and restrict it to Your Android/iOs/web App.

entityMap|blocks|key|3lifk|text|我在github页面上创建了一个博客网站。我有了一个想法，在每个博客页面的末尾嵌入评论。我理解firebase是如何获取和提供数据的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|665bi|我已经测试过很多次了，使用项目，甚至使用控制台。我完全不同意vlit是脆弱的说法。相信我，如果你遵循了firebase推荐的隐私步骤，那么公开展示你的api密钥是没有问题的。转到https://console.developers.google.com/apis并执行安全步骤。^0|0^^$0|$]|1|@$2|3|4|5|6|7|8|E|9|@]|A|@]|B|$]]|$2|C|4|D|6|7|8|F|9|@]|A|@]|B|$]]]]

I am making a blog website on github pages. I got an idea to embbed comments in the end of every blog page. I understand how firebase get and gives you data.
I have tested many times with project and even using console. I am totally disagree the saying vlit is vulnerable.
Believe me there is no issue of showing your api key publically if you have followed privacy steps recommend by firebase.
Go to <a href="https://console.developers.google.com/apis" rel="nofollow noreferrer">https://console.developers.google.com/apis</a>
and perfrom a security steup.

entityMap|blocks|key|75fcf|text|可以包含它们，只有在使用Firebase+ML或使用Firebase身份验证时才需要特别注意|type|unstyled|depth|inlineStyleRanges|entityRanges|data|aqedj|Firebase的API密钥与典型的API密钥不同:与API密钥的通常使用方式不同，Firebase服务的API密钥不用于控制对后端资源的访问；这只能通过Firebase安全规则来完成。通常，您需要谨慎地保护API密钥(例如，通过使用vault服务或将密钥设置为环境变量)；但是，Firebase服务的API密钥可以包含在代码或签入的配置文件中。|ahkvh|尽管Firebase服务的API密钥可以安全地包含在代码中，但在某些特定情况下，您应该强制限制您的API密钥；例如，如果您正在使用Firebase+ML或使用带有电子邮件/密码登录方法的Firebase身份验证。在本页后面了解有关这些案例的更多信息。|52jcn|al2p6|有关更多信息，请查看官方文档^0|0|0|0|0^^$0|$]|1|@$2|3|4|5|6|7|8|J|9|@]|A|@]|B|$]]|$2|C|4|D|6|7|8|K|9|@]|A|@]|B|$]]|$2|E|4|F|6|7|8|L|9|@]|A|@]|B|$]]|$2|G|4|-4|6|7|8|M|9|@]|A|@]|B|$]]|$2|H|4|I|6|7|8|N|9|@]|A|@]|B|$]]]]

It is oky to include them, and special care is required only for Firebase ML or when using Firebase Authentication
<blockquote>
API keys for Firebase are different from typical API keys:
Unlike how API keys are typically used, API keys for Firebase services are not used to control access to backend resources; that can only be done with Firebase Security Rules. Usually, you need to fastidiously guard API keys (for example, by using a vault service or setting the keys as environment variables); however, API keys for Firebase services are ok to include in code or checked-in config files.
</blockquote>
<blockquote>
Although API keys for Firebase services are safe to include in code, there are a few specific cases when you should enforce limits for your API key; for example, if you're using Firebase ML or using Firebase Authentication with the email/password sign-in method. Learn more about these cases later on this page.
</blockquote>
For more informations, check <a href="https://firebase.google.com/docs/projects/api-keys" rel="nofollow noreferrer">the offical docs</a>

The <a href="https://firebase.google.com/docs/web/setup#add_firebase_to_your_app" rel="noreferrer">Firebase Web-App guide</a> states I should put the given <code>apiKey</code> in my Html to initialize Firebase:
<pre class="lang-html prettyprint-override"><code>// TODO: Replace with your project's customized code snippet
&lt;script src=&quot;https://www.gstatic.com/firebasejs/3.0.2/firebase.js&quot;&gt;&lt;/script&gt;
&lt;script&gt;
 // Initialize Firebase
 var config = {
 apiKey: '&lt;your-api-key&gt;',
 authDomain: '&lt;your-auth-domain&gt;',
 databaseURL: '&lt;your-database-url&gt;',
 storageBucket: '&lt;your-storage-bucket&gt;'
 };
 firebase.initializeApp(config);
&lt;/script&gt;
</code></pre>
By doing so, the <code>apiKey</code> is exposed to every visitor.
What is the purpose of that key and is it really meant to be public?

Is it safe to expose Firebase apiKey to the public?

数据库安全

身份验证

验证码

数据库

服务器

云函数

防火墙

Android

 Firebase Web-App指南指出，我应该将给定的apiKey放入我的超文本标记语言中以初始化Firebase： 通过这样做，apiKey向每个访问者公开。该密钥的用途是什么?它真的意味着是公开的吗？

问将Firebase apiKey暴露给公众安全吗？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问将Firebase apiKey暴露给公众安全吗？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问将Firebase apiKey暴露给公众安全吗？
EN