Cómo compartir claves de API de forma segura

No pegues una clave de API en un chat ni en un correo. Envíala como enlace secreto de un solo uso: la clave se cifra en tu navegador, la clave de descifrado se queda en la parte del enlace que va después del #, y la copia almacenada se destruye la primera vez que se abre. Después, rota cualquier clave que ya se haya pegado como texto sin cifrar.

El resto de esta guía entra en detalle: por qué fallan los canales habituales, el procedimiento exacto de entrega, qué hacer si una clave se filtra de todos modos y los casos en los que un enlace de un solo uso no es la herramienta adecuada.

¿Por qué no es seguro enviar una clave de API por Slack o por correo?

Porque los dos guardan el mensaje mientras cualquier sistema lo retenga, y por el camino lo copian en cada dispositivo y en cada exportación.

• En los dos se puede buscar para siempre. Una clave compartida en 2023 puede ser el origen de tu próximo incidente. Los atacantes que entran en el chat o el buzón de una empresa buscan de forma rutinaria justo las cadenas que tienen las claves de API: sk_live, AKIA, ghp_, Bearer.
• Los dos se sincronizan en todas partes. Teléfonos, portátiles personales, tabletas: dispositivos que quedan fuera de tus controles de seguridad y fuera del alcance de tu política de borrado remoto.
• Los dos se exportan. Las revisiones de cumplimiento, los procesos judiciales y las exportaciones del espacio de trabajo generan copias del historial. Cada exportación es otro lugar donde vive la clave.
• Los dos sobreviven a la baja de una persona. El contrato del colaborador externo termina; el hilo de mensajes directos con tu clave de Stripe, no.

Poner un secreto en cualquiera de las dos herramientas significa aceptar que vivirá allí donde acabe el mensaje, mientras algo lo conserve. Ninguno de los dos sistemas se diseñó para olvidar.

Antes de compartir: reduce el alcance de la clave

La mejor entrega es aquella en la que la clave entregada apenas importa. Antes de generar nada, aplica el mínimo privilegio en el origen:

• Limita sus permisos. Claves restringidas de Stripe, tokens de acceso personal con permisos detallados de GitHub, políticas de AWS IAM limitadas a acciones y recursos concretos: la mayoría de los proveedores serios te dejan crear una clave que solo hace lo único que necesita el destinatario.
• Elige solo lectura, salvo que de verdad haga falta escribir.
• Configura la expiración en el proveedor donde la plataforma lo permita (los PAT con permisos detallados de GitHub, las credenciales temporales de AWS mediante STS). Así, incluso una clave filtrada tiene fecha de expiración, pase lo que pase después.
• Ponle el nombre del destinatario (vendor-x-readonly) para que, dentro de seis meses, revocarla sea una decisión de un vistazo y no un trabajo de arqueología.

Con una clave limitada, que expira y de solo lectura, la peor filtración pasa de incidente a simple molestia.

El procedimiento de entrega

1. Genera la clave en el sistema de origen (AWS, Stripe, tu propia API) con los permisos mínimos, como se explica arriba.
2. Pégala en un enlace secreto de un solo uso con «Destruir tras la lectura» activado y la expiración más corta que sirva: 1 hora es la opción predefinida más corta, después vienen 24 horas y 7 días, y el plan Pro permite elegir fecha y hora. Lo justo para la entrega real, ni un minuto más.
3. Añade una frase de contraseña y envíala por otro canal: el enlace por correo y la frase de contraseña por SMS o por mensaje directo de Slack. En LinkPilot, la frase de contraseña, la expiración personalizada y el historial de auditoría son funciones del plan Pro, por 29 USD al mes. Si uno de los dos canales se filtra, el atacante solo tiene la mitad del rompecabezas. (LinkPilot calcula el hash de la frase de contraseña en el navegador con SHA-256 antes de enviarla; la frase original nunca llega a la base de datos ni a los registros del servidor, y los intentos están limitados a 5 por IP y minuto).
4. Envía el enlace.
5. Confirma por otro canal que el destinatario lo ha recibido y revisa el historial de auditoría: una visualización, a la hora y desde el lugar esperados. Ese es tu acuse de recibo.

Si nadie abre el enlace antes de que expire, revócalo y envía uno nuevo. No amplíes la expiración ni lo reutilices.

Ejemplo: entregar una clave restringida de Stripe

# generate a restricted key with the minimum needed scopes
stripe api_keys create \
  --restricted \
  --display-name "vendor-x-readonly"

# pipe the resulting key into a LinkPilot secret
curl -X POST https://api.uselinkpilot.com/v1/secrets \
  -H "Authorization: Bearer $LP_KEY" \
  -d 'payload=sk_restricted_…' \
  -d 'expires_in=3600' \
  -d 'burn_after_read=true'

Lo que ve el destinatario: al abrir el enlace aparece una página con el botón «Mostrar», no la clave. Las vistas previas de los chats y los escáneres de correo que cargan la URL por adelantado solo obtienen metadatos, porque una visualización se registra únicamente con la acción explícita de mostrar, nunca con el GET. Cuando el destinatario hace clic en «Mostrar» (y escribe la frase de contraseña, si la hay), ve la clave exactamente una vez. Después, el contenido almacenado se sobrescribe y el enlace devuelve HTTP 410. Aunque el correo se reenvíe por toda la empresa, solo la primera persona que lo abrió pudo leerlo, y el historial de auditoría te dice quién fue.

Qué canal usar en cada entrega

¿Qué hacer si se filtra una clave de API?

Dala por comprometida y rótala en el proveedor; eliminar el mensaje no sirve de nada. Esto vale para cualquier clave que haya pasado por un mensaje de chat, el cuerpo de un correo, una captura de pantalla, un commit de git o un pegado público. Por este orden:

1. Emite primero la clave de sustitución, si el proveedor permite dos claves activas a la vez. Así evitas cortes para quienes la usan legítimamente.
2. Revoca la clave filtrada en el proveedor. Es el único paso que de verdad pone fin a la exposición; eliminar el mensaje de Slack no lo hace.
3. Entrega la clave nueva como corresponde: enlace de un solo uso, frase de contraseña y expiración corta, según el procedimiento de arriba.
4. Revisa los registros de uso del proveedor para la clave filtrada entre la exposición y la revocación. Si hay llamadas inesperadas, ya no es una limpieza, es un incidente.
5. Corrige el origen del pegado: lleva el secreto a tus herramientas de variables de entorno incluidas en .gitignore, activa el escaneo de secretos en tu servicio de repositorios o actualiza el procedimiento que le dijo a alguien que lo enviara por mensaje directo.

Todo el ciclo debería llevar minutos. Si rotar una clave da tanto miedo que la gente lo evita, esa fragilidad es la verdadera vulnerabilidad: corrígela primero.

Qué evitar

• Volver a enviar el mismo secreto. Rótalo. Reenviarlo borra la garantía de auditoría de «una sola exposición», que es lo que hacía valioso el enlace de un solo uso.
• Plazos de expiración largos. Que sean cortos por defecto. La mayoría de las entregas se completan en minutos; un plazo de 8 horas solo es una filtración más larga.
• Prescindir de la frase de contraseña. Apenas cuesta nada y protege frente a filtraciones accidentales de la URL: correos reenviados, pantallas compartidas en una reunión, miradas indiscretas a una pantalla compartida.
• Capturas de pantalla de claves. Acaban en el carrete de fotos, en la sincronización de fotos en la nube y en la búsqueda de imágenes. Una captura tiene la misma permanencia que pegar en un chat, con peor búsqueda para ti y una búsqueda perfecta para el OCR.
• Usar la herramienta de enlaces como almacén. El enlace es el mensajero, no la bóveda. El destinatario debe guardar la clave en un gestor de contraseñas o en sus herramientas de variables de entorno en cuanto la reciba.

Cuándo un enlace de un solo uso no es la herramienta adecuada

Sección de sinceridad: este método tiene límites.

• Las credenciales entre máquinas van en un gestor de secretos o en el almacén nativo de la plataforma, inyectadas en el despliegue o en tiempo de ejecución. Que una persona haga clic en un enlace no es un paso de despliegue.
• Las credenciales compartidas de larga duración van en un gestor de contraseñas con control de acceso real y revocación por persona.
• La rotación de alta frecuencia (claves que cambian cada hora) debe automatizarse de principio a fin; ni personas ni enlaces deberían formar parte de ese ciclo.
• Secretos que no puedes permitir que toque ningún tercero: haz la entrega fuera de internet. Actualización del 29 de septiembre de 2026: este punto decía al principio que LinkPilot no ofrecía cifrado de extremo a extremo y que había que usar una herramienta con cifrado de extremo a extremo. LinkPilot ahora cifra el texto en el navegador, así que solo almacena texto cifrado, y también los archivos adjuntos. La página de arquitectura de seguridad explica exactamente qué está protegido y qué no.

Para el caso habitual, una persona que entrega una credencial a otra persona una sola vez, el enlace de un solo uso con frase de contraseña y expiración corta es el método sencillo más sólido que existe.

Lecturas relacionadas

• Por qué las URL filtran información confidencial
• Compartir contraseñas de forma segura: 5 métodos comparados
• Arquitectura de seguridad de LinkPilot
• Comparativa de API de acortadores de URL
• Generador gratis de enlaces secretos

Referencias

• Stripe Docs, API keys: limit access with restricted keys.
• GitHub Docs, Managing your personal access tokens.
• AWS IAM User Guide, Temporary security credentials in IAM.