Background
I'm looking at using Google Cloud Endpoints to specify public endpoints on a Kubernetes cluster.
I'm able to create an API key that can access endpoints, and manually specify which endpoints can access an user.
Is there a way to have a "class" of API keys that get access to the same endpoints? Is there a better way?
2 use cases to support
When enabling a new client they should have access to all our public endpoints.
When adding a new public endpoint, it should be applied to all existing keys.
It depends on what are you using:
With gRPC, all API methods require an API key to access them, so, a new API key/client will have access to already existing endpoints. If you later add a new endpoint, all previous existing keys will have access to it.
With OpenAPI, you can restrict access to your methods in a similar manner.
Related
I have created an API with Firebase using Cloud Functions. GET and POST endpoints are deploeyd.
A client application is registered on the project and can access it callable functions.
I would like other client applications (using their own separate Firebase project) being able to access the API too.
However, I am concerned regarding security.
If I create HTTPS endpoints for those applications, anyone having the URL will be able to use the API ?
And if I manage to restrict access only to those authorized apps, can I allow/restrict only specific endpoints (only GET endpoints, for example)?
I am developing a web application using NextJS. I am using firebase, sentry.io and infinite scroll in my project. When the application first runs, my data from the backend comes as server side. If the user scrolls, my new data is necessarily brought as a client side. I defined my key in the .env.local file with the prefix NEXT_PUBLIC since this API will be requested on both client and server sides.
Wouldn't defining it as NEXT_PUBLIC show my api url in the network?
I need to collect events with firebase for user actions. I have to access Firebase as client side. That's why I define my keys with the NEXT_PUBLIC prefix. For example: NEXT_PUBLIC_API_KEY
In such a case, my api key will appear on the network again. Isn't this a security issue?
How can I hide Firebase API Key?
I collect the errors that occur in the project with sentry.io. Likewise, I need to access sentry.io as a client side. When I perform the above scenario, users will access my API key.
If the secrets we define as NEXT_PUBLIC become public, what is the logic of defining them?
I need to request client-side for Infinite scroll and firebase, how can I secure the secrets I use at this point?
I will deploy my projects with docker. Where should I specify these env variables?
Well you can use Google Cloud Secret Manager to store your keys and you can use the Client Library to fetch the keys as you want.
References:
Secret Manager Docs
Secret Manager Client Librarirs Docs
I am using firebase and my backend API to get data for my APP.
The api requires a GCP key from access. This key expires every 90 days. So, I cannot store the key in the client/phone.
Need some ideas of where can I store the key.. I tried Firebase remote config and it works but the Firebase documentation said that sensitive data should not be used .
Creating a backend service that return the keys will not be secure as anyone can call the service,,
Need some suggestion. Is Firestore/Realtime database an option. The app will only read the data. However when the data changes(new keys) the App should get the latest.
Thanks for any suggestion
While distributing a private API key to the app at runtime through a mechanism like Remote Config, or a cloud database, may reduce the risk of it being intercepted, it is not enough to deter a sufficiently motivated malicious user. That's why the Remote Config documentation recommends against it, and the same applies to other distribution mechanisms (such as the databases you mention).
If this is a private API key, you should not use it in client-side code, period. That's really the only solution. When you use it in client-side code, a malicious user may get access to it and then abuse the backend service that is protected by the private API key.
Private API keys should be kept private, and only be used in a trusted environment (such as your development machine, a server you control, or Cloud Functions). When you allow users of your app to make calls through that private environment (by defining your own API for them), you will have to secure that end point yourself to ensure only authorized users can access them.
I want to use Firebase Remote Config API via REST in a mobile app. Due to technical limitations, I can't use the Android/iOS SDK so I have to resort to the REST API.
However, that API requires authentication using a private key -- obviously I can't include that key in the application.
I don't need any other Firebase service at this time, just the remote config.
How can I work around this limitation? I tried following the guide at https://firebase.google.com/docs/remote-config/use-config-rest, but as mentioned it requires to first generate a short-lived OAuth2 token using the auth API.
According to the documentation on using the Remote Config REST API:
This document describes how you can use the Remote Config REST API to read and modify the set of JSON-formatted parameters and conditions known as the Remote Config template.
So the REST API is for modifying Remote Config variables, the type of action you could also do in the Firebase console. It is not for use in regular clients, which consume the configuration variables. For that you'll have to use one of the provided clients, as there is no REST API and the wire protocol is not documented.
Documentation of firebase https://firebase.google.com/docs/web/setup tell us we can safely expose firebase apiKey:
Note: The Firebase config object contains unique, but non-secret
identifiers for your Firebase project.
The tutorial explains how to obtain the apiKey and insert it into the HTML code of our web app. Everyone can read that key. I would understand this is only an identification key.
But recently I received this message from google:
We have detected a publicly accessible Google API key associated with
the following Google Cloud Platform project:
[...]
The key was found at the following URL:
[...]
We believe that you or your organization may have inadvertently
published the affected API key in public sources or on public websites
(for example, credentials mistakenly uploaded to a service such as
GitHub.)
Please note that as the project/account owner, you are responsible for
securing your keys. Therefore, we recommend that you take the
following steps to remedy this situation:
If this key is intended to be public (or if a publicly accessible
key isn’t preventable):
Log in to the Google Cloud Console and review the API and
billing activity on your account, ensuring the usage is in line with
what you expected.
Add API key restrictions to your API key, if applicable.
If this key was NOT meant to be public:
Regenerate the compromised API key: Search for Credentials in
the cloud console platform, Edit the leaked key, and use the
Regenerate Key button to rotate the key. For more details, review the
instructions on handling compromised GCP credentials.
Take immediate steps to ensure that your API key(s) are not embedded in public source code systems, stored in download
directories, or unintentionally shared in other ways.
Add API key restrictions to your API key, if applicable.
In general I would say that the two sources of information are in contrast each-other. Is it true that the apiKey is "non-secret"? Reading also the related question Is it safe to expose Firebase apiKey to the public? I'm not really sure. I understand that the apiKey is enough to access the whole database if rules allow to.
First question: I wonder if I can be assured that the apiKey only gives access to the database (which can be restricted by rules) or if it gives also access to other information about the project. What about storage? The user can read files? Can write them? The key is called "web API key" so I understand is a unique identifier of the project. Before receiving the message from google I have considered it more as an identifier than a key. Since every access to the project API is a potential cost for me, the owner of the project, I understand that a key is required for billing purposes.
Second question. Since I would like to have full control of what user can access in the database my application is presenting a REST api as an interface to the database (using functions). So the user is not supposed to directly access the database. I have the following rules
service cloud.firestore {
match /databases/{database}/documents {
match /global/public {
allow read;
}
}
}
The intention is that user can only read the documents prefixed with /global/public (currently empty). So I think the database is secured. Now I wonder if I really need to expose the apiKey... Is the apiKey required for user authentication? If so, can I ignore the message from google and leave the apiKey public?