Seguridad de claves de API de correo: permisos, rotación y almacenamiento

Una clave de API de correo es una cadena corta con mucho poder. Quien la tenga puede enviar correo desde tu dominio, a cualquiera, en tu nombre. Las claves filtradas son una de las vías más habituales por las que campañas de phishing acaban enviándose desde la infraestructura de empresas legítimas.

La buena noticia: unos pocos hábitos hacen que una filtración sea poco probable y limitan los daños si aun así se produce. Esta guía los repasa usando los controles que Inbixio ofrece en cada clave.

Qué puede hacer una clave de Inbixio

Cada clave que creas en API Keys → Create Api Key (claves de API → crear clave de API) tiene tres ajustes:

• Name (nombre), para tu propia organización; por ejemplo, prod-auth-service.
• Server Access (acceso a servidores): All Server (todos los servidores; envía a través del primer servidor SMTP que conectaste) o Selected Server (servidor seleccionado; exactamente el que elijas).
• Permissions (permisos): Send (enviar), Read (leer) y Manage (gestionar). Actualmente la API tiene un único endpoint, el de envío de correo, así que Send es el permiso que necesitan tus servicios.

Las claves tienen el formato ibx_ seguido de 32 caracteres hexadecimales. El prefijo hace que sean fáciles de reconocer, y fáciles de detectar para los escáneres de secretos.

Regla 1: una clave por servicio y entorno

No compartas una sola clave en toda la empresa. Crea una clave distinta para cada servicio y para cada entorno:

Tener claves separadas significa que:

• Una filtración queda contenida. Revocar prod-billing no detiene los correos de inicio de sesión.
• Cada servicio envía desde la dirección correcta. Una clave fijada al servidor billing@ envía desde billing@, no desde el primer servidor que conectaste. Si eliminas un servidor fijado, la clave vuelve a tu primer servidor, así que vuelve a fijar las claves cuando elimines servidores.
• La rotación es sencilla. Puedes renovar la clave de un servicio sin tocar las demás.

Regla 2: concede el mínimo permiso que funcione

Un backend que envía correo necesita Send y nada más, así que deja Read y Manage sin marcar. Cuanto menos pueda hacer una clave, menos costará una filtración.

Regla 3: las claves viven en servidores, nunca en clientes

Cualquier cosa que se entregue a un navegador o a una app móvil puede extraerse, esté minificada o no. Eso incluye:

• los bundles de JavaScript (React, Vue, componentes de cliente de Next.js),
• las variables de entorno con prefijo para el navegador, como NEXT_PUBLIC_, VITE_ o REACT_APP_,
• los binarios de apps de iOS y Android.

Si una acción del usuario en tu frontend debe generar un correo, llama a un endpoint de tu propio backend. Tu backend comprueba que el usuario tiene permiso para hacerlo, aplica límites de frecuencia y solo entonces llama a Inbixio con la clave que guarda en su entorno.

// ✅ Browser → your API → Inbixio
await fetch('/api/invite', { method: 'POST', body: JSON.stringify({ email }) });

// ❌ Never do this in frontend code
fetch('https://backend.inbixio.com/api/send-email/', {
  headers: { 'X-API-Key': 'ibx_…' }, // visible to every visitor
});

Regla 4: guarda las claves como contraseñas

• Guarda las claves en un gestor de secretos (AWS Secrets Manager, Google Secret Manager, Doppler, 1Password, Vault) o en las variables de entorno cifradas de tu plataforma.
• No las incluyas nunca en un commit. Añade .env a .gitignore y activa el escaneo de secretos en tus repositorios; la protección de push de GitHub bloquea muchas filtraciones antes de que ocurran.
• Mantén las claves fuera de los registros. Si registras las solicitudes salientes, elimina antes la cabecera X-API-Key.
• No pegues claves en tickets, chats ni capturas de pantalla. Comparte el acceso al secreto, no su valor.

Regla 5: rota según un calendario, y de inmediato ante la duda

Inbixio puede renovar una clave: haz clic en el icono de actualizar junto a ella en la página API Keys. La renovación emite un valor nuevo con el mismo nombre, el mismo acceso a servidores y los mismos permisos, y el valor antiguo deja de funcionar al instante. Para rotar una clave de producción sin envíos fallidos:

1. Crea una segunda clave con los mismos ajustes (por ejemplo, prod-auth-2).
2. Despliega la clave nueva en el servicio y confirma que sus solicitudes devuelven 200, por ejemplo en los registros de tu propia aplicación.
3. Elimina la clave antigua.

Usa el icono de actualizar cuando la rapidez importe más que un relevo sin interrupciones, como justo después de una filtración. Rota las claves habituales cada pocos meses y siempre que alguien con acceso deje el equipo.

Si se filtra una clave

Trátalo como un incidente, pero uno manejable:

1. Renueva (icono de actualizar) o elimina la clave de inmediato. Así se detiene todo uso del valor antiguo.
2. Revisa los registros del panel en busca de actividad inusual: llamadas a horas extrañas o un pico de volumen. El registro muestra cuándo se hicieron las llamadas, no qué clave las hizo, así que compáralo con los registros de tus propios servicios.
3. Revisa tu proveedor de correo en busca de rebotes o quejas de spam causados por mensajes que no enviaste.
4. Averigua cómo se filtró, ya sea un commit, una línea de registro o un bundle del frontend, y cierra esa vía.
5. Avisa a los usuarios afectados si se enviaron mensajes en tu nombre, para que sepan que deben ignorarlos.

Una lista de comprobación rápida

• Una clave por servicio y entorno, con nombres claros
• Claves fijadas al servidor (dirección remitente) que debe usar cada servicio
• Solo el permiso Send en los servicios que envían
• Ninguna clave en código de frontend, apps móviles ni repositorios
• Claves guardadas en un gestor de secretos y eliminadas de los registros
• Una fecha de rotación en el calendario y un plan ante filtraciones

La seguridad también es lo que te mantiene fuera de la carpeta de spam: los mensajes enviados desde una clave comprometida dañan la reputación de tu dominio. Combina esta lista con SPF, DKIM y DMARC para tener la visión completa.