Un sitio que usa un CRM, un servicio de pago, una API de cartografía o una herramienta de envío de correos casi siempre maneja claves de acceso, también llamadas secretos, que permiten a esos servicios externos identificar y autorizar las solicitudes enviadas desde el sitio. Estas claves funcionan como contraseñas, con una diferencia importante: a menudo se copian, se comparten y se integran en código sin que nadie se plantee su nivel real de protección.

El error más frecuente: la clave escrita directamente en el código

En un desarrollo PHP a medida, sigue siendo habitual encontrar una clave API escrita directamente en un archivo de configuración versionado junto con el resto del código fuente. El problema surge en cuanto ese código se comparte, ya sea a través de un repositorio Git privado accesible a un proveedor externo, una exportación a un nuevo desarrollador, o, peor aún, un repositorio que se vuelve público por accidente. Una vez que una clave ha circulado por un historial de versiones, eliminarla del código actual no basta: sigue siendo legible en versiones anteriores hasta que se revoque y se sustituya por una nueva.

La buena práctica básica: las variables de entorno

La solución estándar consiste en sacar las claves del código fuente y almacenarlas en variables de entorno, normalmente mediante un archivo llamado .env, que nunca se incluye en el repositorio de código gracias a un archivo .gitignore que lo excluye explícitamente. El código de la aplicación lee entonces la clave desde esa variable en tiempo de ejecución, sin escribirla nunca en claro en un archivo controlado por el control de versiones. Este enfoque sigue siendo adecuado para un desarrollo local o un sitio de tamaño modesto, siempre que ese archivo nunca se envíe por correo o mensajería instantánea, canales que dejan rastros difíciles de borrar por completo.

Lo que este archivo no protege

Un archivo .env correctamente excluido del repositorio de código sigue estando presente en claro en el servidor de producción, lo que significa que un acceso no autorizado al servidor, por ejemplo a través de un fallo en un plugin de WordPress o una contraseña FTP comprometida, expone directamente todas las claves que contiene. Para un sitio con requisitos de seguridad más elevados, en particular cuando varias personas o proveedores intervienen en la infraestructura, un gestor de secretos dedicado, como los que ofrecen los grandes proveedores de nube, permite un almacenamiento cifrado con un control preciso de quién puede consultar cada clave, lo que va más allá de lo que ofrece un simple archivo local.

La trampa del frontend y el código visible por el navegador

Una clave integrada en código JavaScript ejecutado en el navegador, incluso en un archivo compilado o minificado, sigue siendo técnicamente accesible para cualquiera que inspeccione el código fuente de la página. Es un error frecuente cuando se añade rápidamente una integración de terceros sin hacer pasar la solicitud por el servidor del sitio. La solución consiste en enrutar esas llamadas a través de un punto de entrada del lado del servidor, que conserva la clave en secreto y solo transmite al navegador el resultado necesario, nunca la clave en sí.

Restringir cada clave a su uso estricto

La mayoría de los servicios permiten limitar una clave API a un dominio concreto, un rango de direcciones IP, o un conjunto de acciones autorizadas, una función a menudo ignorada por simplicidad en el momento de crear la clave. Esta restricción no cuesta nada implementar y reduce mucho el impacto de una posible filtración, ya que una clave limitada a nikaia.net no puede reutilizarse desde otro dominio aunque se descubra.

Renovar las claves, no solo protegerlas

Una clave creada al lanzar un proyecto y nunca renovada desde entonces sigue siendo un riesgo que se acumula con el tiempo, en particular cuando varios proveedores o empleados han tenido acceso a ella a lo largo de los años sin que se mantenga actualizada la lista de personas implicadas. Una renovación periódica, incluso sencilla, limita la ventana de explotación de una clave que pudiera haberse filtrado sin que nadie se percatara.

Puntos a verificar antes de publicar: confirmar que la descripción del funcionamiento de los archivos .env y su exclusión mediante .gitignore sigue correspondiendo a las prácticas estándar de desarrollo PHP en el momento de la publicación, y comprobar que los ejemplos de gestores de secretos mencionados siguen siendo soluciones habitualmente usadas en el mercado.