Qué hacer cuando tus claves API terminan en un repositorio
Subiste código a GitHub y segundos después te diste cuenta de que tu clave API se fue con él. Tal vez GitHub te envió una alerta. Tal vez GitGuardian te envió un correo. De cualquier manera, ahora estás lidiando con secretos expuestos en aplicaciones frontend—y el reloj está corriendo.
Aquí está lo crítico que la mayoría de los desarrolladores hacen mal: eliminar la clave de tu último commit no soluciona el problema. El historial de Git preserva todo. Puede que ya existan forks. Los bots automatizados escanean repositorios públicos en segundos después de un push.
Este artículo cubre exactamente qué hacer cuando las claves API se filtran en GitHub, cómo distinguir entre secretos verdaderamente sensibles y claves públicas de cliente, y cómo prevenir que esto vuelva a suceder.
Puntos clave
- Revoca y rota los secretos expuestos inmediatamente—limpiar el historial de Git es secundario ya que la clave ya está comprometida.
- Distingue entre claves públicas de cliente (diseñadas para uso en navegador) y secretos verdaderos (credenciales privilegiadas que requieren acción urgente).
- El historial de Git preserva todo, por lo que eliminar un commit no remueve el secreto de forks, cachés o clones existentes.
- Habilita la protección de push de GitHub para bloquear commits que contengan secretos antes de que lleguen a tu repositorio.
- Nunca almacenes claves privilegiadas en código frontend—usa rutas API del lado del servidor o proxies backend en su lugar.
Primero, entiende qué expusiste realmente
No todas las claves conllevan el mismo riesgo. Antes de entrar en pánico, identifica qué tipo de credencial se filtró.
Las claves públicas de cliente están diseñadas para ser visibles. Claves API de Google Maps restringidas a dominios específicos, tokens de analítica, o claves explícitamente prefijadas para uso del lado del cliente (como NEXT_PUBLIC_ en Next.js o VITE_ en Vite) están destinadas a incluirse en bundles de navegador. Estas aún deben tener restricciones de uso, pero la exposición no es catastrófica.
Los secretos verdaderos otorgan acceso privilegiado: claves secretas de Stripe, credenciales de AWS, cadenas de conexión a bases de datos, o cualquier clave que pueda leer/escribir datos sensibles o generar cargos. Estos requieren acción inmediata.
La distinción importa porque tu respuesta debe coincidir con la severidad.
Respuesta inmediata: revoca y rota primero
Cuando has filtrado un secreto verdadero, la limpieza del historial es secundaria. Tu primera prioridad es rotar las claves API comprometidas.
Paso 1: Revoca la clave expuesta inmediatamente. Inicia sesión en el panel de control de tu proveedor de API y elimina o deshabilita la credencial comprometida. No esperes hasta haber limpiado el historial de Git—la clave ya está comprometida.
Paso 2: Genera una nueva clave con alcance mínimo. Aplica el principio de mínimo privilegio. Restringe por IP, dominio o endpoints API específicos donde sea posible.
Paso 3: Actualiza tu aplicación. Despliega la nueva clave a tus entornos antes de que tu aplicación falle.
Algunos proveedores de nube automáticamente deshabilitan credenciales que detectan en repositorios públicos. Por ejemplo, Google Cloud puede deshabilitar automáticamente claves de cuentas de servicio expuestas por defecto. Otros, incluyendo AWS, típicamente te notifican pero no revocan claves automáticamente de manera consistente. Todos estos proveedores participan en el programa de escaneo de secretos de GitHub. No confíes en la automatización—actúa inmediatamente de todos modos.
Por qué eliminar el commit no es suficiente
Git nunca olvida. Incluso si eliminas el secreto de tu rama actual, vive en:
- Commits anteriores accesibles vía
git log - Forks creados antes de tu corrección
- Clones existentes descargados por otros usuarios o bots
- Cualquier espejo hecho antes de la eliminación
Por esto la revocación viene primero. La limpieza del historial es contención, no remediación.
Si necesitas limpiar el historial, herramientas como git filter-repo o BFG Repo-Cleaner pueden ayudar. Pero entiende que si tu repositorio fue público por cualquier período de tiempo, asume que el secreto fue capturado.
Discover how at OpenReplay.com.
Escaneo de secretos y protección de push de GitHub
GitHub ofrece protección de primera clase contra este problema exacto. El escaneo de secretos y la protección de push están disponibles para todos los repositorios públicos y para repositorios privados vía GitHub Secret Protection (también incluido en GitHub Advanced Security).
El escaneo de secretos detecta patrones de credenciales conocidos en tu repositorio y te alerta a ti y/o al proveedor automáticamente.
La protección de push va más allá—bloquea commits que contengan secretos detectados antes de que lleguen al repositorio. Este es el mecanismo de prevención más efectivo disponible.
Habilita ambos en la configuración de tu repositorio bajo Settings → Code security and analysis, o consulta la documentación oficial sobre GitHub Secret Protection.
La trampa de las variables de entorno en frontend
Aquí hay un error que atrapa a muchos desarrolladores de React, Vue y Next.js: las variables de entorno prefijadas para uso del cliente no son secretos.
Variables como REACT_APP_*, NEXT_PUBLIC_*, o VITE_* se incluyen directamente en tu JavaScript. Cualquiera puede abrir DevTools y encontrarlas. Estas no están ocultas—solo están organizadas.
Si una clave otorga acceso privilegiado, no puede vivir en código frontend. Punto.
Estrategias de prevención para equipos frontend
Mantén las claves privilegiadas del lado del servidor. Usa rutas API, funciones serverless o un proxy backend. Tu frontend autentica usuarios; tu backend guarda los secretos.
Habilita la protección de push. Esto atrapa errores antes de que se conviertan en incidentes.
Usa hooks pre-commit. Herramientas como gitleaks o detect-secrets escanean cambios preparados localmente.
Añade escaneo en CI. Ejecuta detección de secretos en tu pipeline como red de seguridad.
Restringe las claves agresivamente. Incluso las claves públicas de cliente deben estar limitadas por dominio, IP o alcance de API.
Conclusión
Cuando las claves API se filtran, la velocidad importa más que la perfección. Revoca primero, rota inmediatamente, luego limpia el historial como paso secundario. No confundas claves públicas de cliente con secretos verdaderos, y nunca confíes en que las variables de entorno oculten algo en builds de frontend.
Habilita la protección de push de GitHub hoy. Es la manera más fácil de asegurar que este problema nunca vuelva a suceder.
Preguntas frecuentes
Revoca o deshabilita la clave expuesta inmediatamente a través del panel de control de tu proveedor de API. No esperes a limpiar tu historial de Git primero. La clave ya está comprometida en el momento en que se subió a un repositorio público, y los bots automatizados pueden capturarla en segundos. Después de la revocación, genera una nueva clave y actualiza tu aplicación.
No. Git preserva todo el historial, por lo que el secreto permanece accesible en commits anteriores, forks, clones existentes y cualquier copia hecha antes de tu corrección. Eliminar o modificar el commit solo lo remueve de la punta de la rama actual. Debes revocar la clave independientemente de cualquier limpieza del historial que realices después.
No. Estas variables de entorno prefijadas se incluyen directamente en tu JavaScript frontend y son visibles para cualquiera que abra DevTools del navegador. Están destinadas para valores de configuración públicos, no para secretos. Cualquier clave que otorgue acceso privilegiado debe almacenarse del lado del servidor y accederse a través de rutas API o proxies backend.
Habilita la protección de push de GitHub para bloquear commits que contengan secretos detectados antes de que lleguen a tu repositorio. Usa hooks pre-commit con herramientas como gitleaks o detect-secrets para escanear cambios localmente. Añade detección de secretos a tu pipeline de CI como red de seguridad adicional. Estas capas trabajan juntas para atrapar errores temprano.
Understand every bug
Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.
