Solución:
La apiKey en este fragmento de configuración solo identifica su proyecto de Firebase en los servidores de Google. No es un riesgo para la seguridad que alguien lo sepa. De hecho, es necesario que lo sepan, para que puedan interactuar con tu proyecto de Firebase. Estos mismos datos de configuración también se incluyen en todas las aplicaciones de iOS y Android que usan Firebase como su backend.
En ese sentido, es muy similar a la URL de la base de datos que identifica la base de datos back-end asociada con su proyecto en el mismo fragmento: https://<app-id>.firebaseio.com. Vea esta pregunta sobre por qué esto no es un riesgo de seguridad: ¿Cómo restringir la modificación de datos de Firebase ?, incluido el uso de las reglas de seguridad del lado del servidor de Firebase para garantizar que solo los usuarios autorizados puedan acceder a los servicios de backend.
Si desea saber cómo proteger todos los datos que el acceso a sus servicios de backend de Firebase está autorizado, lea la documentación sobre las reglas de seguridad de Firebase. Estas reglas controlan el acceso al almacenamiento de archivos y a la base de datos, y se aplican en los servidores de Firebase. Así que no importa si es tu código, o el código de otra persona que usa sus datos de configuración, solo puede hacer lo que las reglas de seguridad le permiten hacer.
Para obtener otra explicación de para qué utiliza Firebase estos valores y para cuál de ellos pueden establecer cuotas, consulte la documentación de Firebase sobre el uso y la administración de claves de API.
Si desea reducir el riesgo de asignar estos datos de configuración al control de versiones, considere usar la configuración automática del SDK de Firebase Hosting. Si bien las claves aún terminarán en el navegador en el mismo formato, ya no estarán codificadas en su código con eso.
Sobre la base de las respuestas de prufrofro y Frank van Puffelen aquí, armé esta configuración que no evita el raspado, pero puede dificultar un poco el uso de su clave API.
Advertencia: Para obtener sus datos, incluso con este método, uno puede, por ejemplo, simplemente abrir la consola JS en Chrome y escribir:
firebase.database().ref("/get/all/the/data").once("value", function (data) {
console.log(data.val());
});
Solo las reglas de seguridad de la base de datos pueden proteger sus datos.
Sin embargo, restringí el uso de mi clave API de producción a mi nombre de dominio de esta manera:
- https://console.developers.google.com/apis
- Seleccione su proyecto de Firebase
- Cartas credenciales
- En Claves de API, elija la clave de su navegador. Debe tener un aspecto como este: “Clave del navegador (creada automáticamente por el servicio de Google)“
- En “Acepte solicitudes de estas referencias HTTP (sitios web)“, agregue la URL de su aplicación (ejemplo:
projectname.firebaseapp.com/*)
Ahora la aplicación solo funcionará en este nombre de dominio específico. Así que creé otra clave de API que será privada para el desarrollo de localhost.
- Haga clic en Crear credenciales> Clave API.
De forma predeterminada, como lo menciona Emmanuel Campos, Firebase solo incluye listas blancas localhost y su dominio de alojamiento de Firebase.
Para asegurarme de que no publico la clave API incorrecta por error, utilizo uno de los siguientes métodos para usar automáticamente el más restringido en producción.
Configuración para Create-React-App
En /env.development:
REACT_APP_API_KEY=###dev-key###
En /env.production:
REACT_APP_API_KEY=###public-key###
En /src/index.js
const firebaseConfig = {
apiKey: process.env.REACT_APP_API_KEY,
// ...
};
No estoy convencido de exponer las claves de seguridad / configuración al cliente. No lo llamaría seguro, no porque alguien pueda robar toda la información privada desde el primer día, porque alguien puede hacer una solicitud excesiva, agotar tu cuota y hacerte deber mucho dinero a Google.
Debe pensar en muchos conceptos, desde restringir a las personas para que no accedan a donde se supone que no deben estar, ataques de DOS, etc.
Preferiría más que el cliente primero llegue a su servidor web, allí coloque el firewall de primera mano, captcha, cloudflare, seguridad personalizada entre el cliente y el servidor, o entre el servidor y la base de fuego y listo. Al menos, primero puede detener la actividad sospechosa antes de que llegue a la base de fuego. Tendrás mucha más flexibilidad.
Solo veo un buen escenario de uso para usar la configuración basada en el cliente para usos internos. Por ejemplo, tiene un dominio interno y está bastante seguro de que los forasteros no pueden acceder allí, por lo que puede configurar un entorno como el navegador -> tipo de base de fuego.