Una clave API aparece en su web: ¿basta con borrarla?

El nombre de la variable no revela permisos

Imagine una página creada con IA que llama a un servicio de correo desde el navegador. El JavaScript contiene API_KEY. Ese nombre no demuestra un fallo. Consulte la documentación: ¿identificador público, clave de cliente restringida o secreto que autoriza acciones? No pruebe credenciales de webs ajenas. Es un ejemplo, no un incidente comunicado.

En su servicio, pida al titular que confirme tipo y permisos en la consola. Anote URL del script y hora del hallazgo sin copiar el valor completo a correos, incidencias o chats con IA. Ocúltelo también en las capturas.

Corte el acceso antes de limpiar cada copia

Si se confirma un secreto expuesto, coordine pronto su revocación o sustitución con el responsable. GitHub también sitúa este paso antes de limpiar el historial. Reconstruir la página elimina una vía de distribución, pero no impide usar una copia anterior.

Lleve las operaciones con secretos al servidor y guarde la nueva credencial en un almacén adecuado del servidor. Compruebe que el build no la introduce de nuevo en archivos públicos: las variables de entorno pueden acabar en el código del navegador. Si la función no puede operar con seguridad durante el cambio, acuerde una pausa temporal en lugar de exponer otra clave.

Una factura normal no cierra la investigación

Revise los registros de uso y auditoría disponibles para el posible periodo de exposición. Separe lo que permitía la clave de lo que muestran los registros. Una factura estable no demuestra ausencia de acceso a datos; la falta de logs limita la comprobación. Derive los indicios de uso no autorizado al proceso de incidentes del responsable.

Enumere las copias controladas: scripts publicados, cachés CDN, repositorios, builds y materiales de diagnóstico compartidos. Coordine la limpieza del historial; reescribirlo afecta a colaboradores y no borra sus clones. Restrinja el expediente del incidente y oculte los secretos.

Qué comprobar después del cambio

Con su propia cuenta autorizada, confirme la revocación de la credencial antigua y los permisos mínimos de la nueva. Compruebe que los archivos del navegador ya no contienen el secreto y que la función normal sigue operativa. Anote versión y hora. No genere cargos a terceros para demostrar el impacto.

Un control externo puede detectar credenciales visibles. Revisar logs del proveedor, rotar claves, revisar código y responder a incidentes son trabajos distintos, no incluidos en el paquete público Mingxi. Tampoco demuestra que la clave nunca se utilizó. Mantenga visibles los puntos sin verificar al entregar el trabajo.

Lista práctica

• Confirme el tipo con proveedor y responsable.
• Revoque o sustituya pronto los secretos expuestos.
• Revise logs disponibles y oculte secretos en las pruebas.
• Compruebe el despliegue y la función normal.

Pregunta frecuente

¿Hay que quitar cualquier clave del JavaScript?

No. Algunas claves de cliente son públicas por diseño. Siga los requisitos del proveedor sobre permisos y restricciones. Un identificador publicable no equivale a un secreto del servidor.