Protegiendo tus tokens, claves API y secretos

¿Público? ¿Privado? ¿Qué?

¿Cuándo proteger tus tokens?

¡Proteger las claves y tokens de API es críticamente importante!

¡Un solo error puede hacer que los hackers tomen el control de tu servidor y tus datos!

No debería ser tan difícil determinar si un token concreto debe ocultarse, incluso basándose en la documentación oficial!

A menudo se complica aún más con la sopa de términos relacionados que encontrarás: tokens, keys, credentials, secrets, private y public.

Replanteémoslo como una distinción entre secret y non-secret.

• 🔒 Secret keys DEBEN mantenerse ocultas. En general, nunca deben salir de tu servidor privado (o servicio — como Heroku, Netlify o Travis‑CI).
• 🌍 Non-secret keys describe cadenas que pueden compartirse libremente e incluirse en solicitudes del navegador.

🔒 Secret keys

** ‼️ Importante:** Secret keys DEBEN ser ignoradas por Git Y omitidas en todo el código del navegador. Cómo usar dotenv

¿Cómo sabes cuándo estás tratando con una Secret key?

👍 Regla práctica: los servidores que devuelven CORS errors carecen de soporte en el navegador. Eso indica fuertemente que DEBES proxyar el servicio, tratándolo como si fuera secret.

👍 Regla práctica: los servicios costosos deberían (casi) siempre ser proxyados u ocultos.

👍 Regla práctica: si realizas una operación de escritura (carga de archivos, inserción de fila en base de datos), podrías estar tratando con secret keys.

Casos de uso y características: Secret keys

• Autorización a largo plazo (credenciales, tokens de acceso, JSON Web Tokens)
• Autorización a corto plazo (tokens OAuth, almacén de sesiones)
• Acceso a servicios pagos/costosos (para autenticación, geocodificación, almacenamiento de archivos, etc.)
• Parte privada de un par público/privado (RECAPTCHA, Stripe, Auth0)
• Credenciales de servicio (Email/SMTP, LDAP/Servicios de Directorio)
• Cifrado de datos y verificación de integridad

Lista de verificación: Manejo seguro de secretos

Visión rápida

Complete los siguientes pasos para eliminar secretos de su código:

• Reemplace las claves codificadas en duro por variables de entorno. p. ej. process.env.API_SECRET
• Use una biblioteca como dotenv junto con un archivo .env. Añada los secretos que antes estaban codificados en el archivo .env.
• ¡Agregue una línea .env a su archivo .gitignore!

NO cree un archivo .env en los servidores de producción. Utilice la herramienta de gestión de variables de entorno que provee su servicio de hosting (p. ej. Heroku, Netlify, AWS EC2): p. ej. panel de control o línea de comandos.

Artículo relacionado: Uso seguro de dotenv en NodeJS

🌍 Non-secret keys

👍 Regla práctica: siempre que una clave deba enviarse al navegador en código o inline (p. ej. mediante una etiqueta <script src="https://my-api/?apiKey=123-abc-456">), definitivamente es una non-secret. Un ejemplo típico es Google Maps.

Casos de uso y características: claves Non-secret

• Acceso a corto plazo (IDs de sesión de usuario, JSON Web Tokens)
• Limitar el acceso a la API por aplicación/desarrollador (para autenticación, geocodificación, etc.)
• Parte pública de un par público/privado (RECAPTCHA, Stripe, Auth0)
• IDs de analítica

✅ Manejo de no‑secretos:

¡Es seguro codificar en duro claves no‑secretas (públicas)!

Haz que sea más fácil de gestionar a largo plazo usando un archivo config.js compartido para tu aplicación.

Ejemplo:

module.exports = {
  googleMapsKey: '123-abc'
};

const config = require('./config.js');
const key = config.googleMapsKey;
const src = `//maps.googleapis.com/maps/api/js?key=${key}`;
// ...

Nota: Existen otros Casos de Uso para variables de entorno. Algunos que no cubrí: CI/CD/pruebas, banderas de características y configuración en tiempo de ejecución para entornos especiales.