Es increíble la cantidad de veces que encontré este problema. Pasó hace unos días, ya lo estaba olvidando cuando… ¡Pum! Otra vez.
Parece ser que con tanto JS por todos lados, nos olvidamos que también puede correr en el navegador. Y que el navegador tiene una opción para ver el código fuente.
El problema es que no existe una forma confiable de proteger una clave. Muchos desarrolladores se fían de la opción de restringir una clave por dominio, como tienen AWS o GCP. Pero esta opción es solo disuasoria: Solo protege la clave de un desarrollador vago, que la copie y pegue en su web. Pero puede comprobarse lo fácil que es saltear esa protección solo con hacer una solicitud desde Postman – al usarse fuera del navegador, ya no hay protección por dominio.
También puede que nos confiemos de mecanismos de obfuscación como Identity Pool de AWS, que no requiere claves API… Pero ocurre lo mismo, copiando el IdentityPoolId pueden generarse claves privadas, temporales pero perfectamente usables. Para peor, ni siquiera es necesario encontrar y copiar el IdentityPoolId: Las credenciales actualmente en uso en tu navegador están visibles en AWS.config.credentials.
Incluso cuando el acceso sea de solo lectura, creas que de bajo riesgo… la factura de AWS o GCP puede crecer rápidamente.
La solución es muy simple: Crea un API (o un endpoint en tu API existente) para consumir desde el servidor todo servicio que requiera una clave o autenticación de cualquier tipo.
En este endpoint, podés hacer validaciones de seguridad, pre o post-procesar los datos, o guardar la respuesta en cache. Por ejemplo, con mapas estáticos de Google Maps, no es necesario generarlo en cada solicitud… ni mucho menos usar la URL de Google Maps directamente en un <img>…
Cuidado también con el uso de claves en frameworks full-stack como Next.js: Asegurate de siempre hacerlo en componentes del lado del servidor.
Otro caso común es utilizar claves en el código, o en archivos de configuración o .env, que es publicado en un repositorio. Esto es mala práctica incluso si el proyecto es privado y estás solo. Las claves quedarán en el historial y el día que se incorpore otra persona, tendrás que invertir tiempo en localizarlas y renovarlas en todos los entornos.
Hay algunas soluciones de baja tecnología para esto:
- Conservá las claves en tu equipo y publicá archivos de configuración de ejemplo
- Almacená los archivos de configuración con claves reales solo en el servidor
Pero ojo con el «sprawl». Estas ideas pueden ayudar en el inicio, pero existen mejores opciones, como utilizar secretos. Ya hablaremos de eso.