Por qué el plugin de pagos no debería traer tus claves

El paquete del plugin de Paymos no lleva credenciales. El archivo que descarga un comercio para WooCommerce, Magento 2 o cualquiera de los otros seis plugins oficiales es el mismo que descargan todos los demás: dentro no hay ninguna clave de API ni secreto de API, ningún ID de proyecto, ningún secreto de webhook, ningún token de OAuth y ningún device code. Descargarlo no conecta nada.

Ningún paso posterior las mete ahí. Conectar una tienda es una sola aprobación, y de ahí salen las claves, el webhook y el vínculo con el proyecto; después se guardan cifradas del lado de la tienda, sin casilla donde escribirlas ni editarlas a mano.

Que el archivo esté vacío es el objetivo, no un detalle. Un paquete armado por comercio, con las claves ya dentro, es un secreto vivo en un fichero, y un fichero viaja: a la carpeta de descargas, a la copia de seguridad nocturna, al adjunto de un ticket y al repositorio de la tienda.

La instalación la cuentan la guía de WooCommerce y las siete páginas de al lado; elegir plugin es asunto del catálogo. Aquí está la capa de debajo: qué puede llevar un paquete, qué lleva el de Paymos y cómo compruebas el tuyo.

¿Qué contiene el paquete de un plugin de pagos?

El paquete de un plugin de pagos es un archivo de código: la extensión que instala el CMS y los ficheros que se la describen a la tienda. Su contenido es igual para todo el que lo descarga, y nada de lo que hay dentro pertenece al comercio que acaba de descargarlo.

Vale la pena abrirlo por lo que una integración en marcha termina necesitando: una clave de API, un secreto de API, un vínculo con un proyecto y un secreto de webhook. La pasarela elige entonces cuándo existen esas cuatro cosas: al construir el paquete, escritas en el fichero, o al conectar, emitidas después.

Paymos elige el momento de conectar. La descarga entrega un fichero estático en lugar de armar uno por cuenta, así que el archivo es idéntico para todos los comercios y no lleva ninguno de esos datos. Comprobarlo se hace desde fuera, sin pedirle permiso a nadie.

¿Por qué habría claves dentro de una descarga?

Una pasarela escribe credenciales en la descarga para quitarle configuración al comercio. El razonamiento une dos cosas: una tienda que no configura nada tuvo que recibir algo que ya sabía de quién era.

El atajo lo paga el archivo. Una clave escrita dentro convierte el código en un documento al portador: quien tiene el fichero tiene la cuenta para la que se construyó, y tener un fichero es un listón muy bajo. Recuperarlo ya no es posible.

Una clave incrustada también pega dos sucesos distintos. Conseguir el código no exige cuenta y se repite tantas veces como haga falta; conectar una tienda va autenticado y ocurre una sola vez.

MITRE cataloga la forma general como CWE-798, Use of Hard-coded Credentials: «The product contains hard-coded credentials, such as a password or cryptographic key». El caso clásico es un secreto compartido por todas las instalaciones; un paquete por comercio le da la vuelta y reparte uno distinto a cada artefacto, pero conserva lo que importa: un secreto vivo dentro de un fichero que circula.

¿Por cuántas manos pasa el archivo del plugin?

El archivo del plugin no se queda donde aterrizó. La carpeta de descargas es la primera de varias paradas, y ninguna de las siguientes se eligió pensando en que dentro hubiera un secreto:

• La carpeta de descargas de un portátil, sin cifrar, todo el tiempo que nadie la ordene.
• La copia de seguridad nocturna del sitio, y detrás cada punto de restauración que dejó.
• El adjunto de un ticket de soporte, en el minuto en que alguien manda «el plugin» a quien le está ayudando.
• El repositorio del sitio bajo control de versiones, al lado de la plantilla.
• El ordenador del freelance o de la agencia que monta la tienda, porque reenviar el fichero es la forma más rápida de pasar el trabajo.

Para un archivo sin credenciales, las cinco paradas no significan nada: el fichero lleva bytes públicos y no revela nada. Para un archivo con una clave escrita dentro, las cinco son una filtración, y el comercio no tiene ningún registro de cuántas ocurrieron ya.

¿Cómo compruebas el paquete que te entregan?

Un paquete de plugin se comprueba descomprimiéndolo y buscando dentro, antes de que llegue a la tienda. Tres órdenes cierran la pregunta y ninguna necesita la colaboración de la pasarela.

# 1. descomprime el archivo antes de que entre en la tienda
unzip -q plugin.zip -d pkg

# 2. busca cualquier cosa con forma de credencial viva
grep -rIn -iE 'api[_-]?key|secret|token|client_id|device_code' pkg

# 3. calcula el hash y compáralo con otra descarga de la misma versión
shasum -a 256 plugin.zip

La -i del segundo paso no es adorno: una constante se escribe API_KEY o ApiKey tanto como api_key, y buscar distinguiendo mayúsculas pasa de largo por dos de las tres formas. En el código fuente público del plugin de Paymos para WooCommerce, ese patrón devuelve 69 líneas con -i y 67 sin ella, contadas sobre el árbol de fuentes y no sobre el archivo publicado.

Lee los resultados como nombres de campo, etiquetas y cadenas de traducción, no como hallazgos. En ese mismo árbol, 38 caen bajo tests/, donde plantillas como 'api_key' => 'pk_test_1234567890' están a propósito. Hay que pararse en un valor real fuera de una carpeta de pruebas.

La suma de verificación cierra lo que la búsqueda solo insinúa. Descarga la misma versión desde otro ordenador y calcula su hash: un archivo idéntico para todos da el mismo hash dos veces; uno armado por cuenta no puede.

¿De dónde salen entonces las credenciales?

Las credenciales salen de una sola aprobación. Instala la versión, pulsa Conectar Paymos en la administración de la tienda, aprueba la petición en la pestaña de Paymos, y ese paso emite el resto sin una casilla que rellenar:

• Claves. Se reutiliza la única clave Payment activa del comercio, o se crea una si no hay ninguna; Sandbox y Live llegan juntas, así que pasar a Live más adelante no pide una segunda conexión.
• Webhook. El webhook de facturas lo registra la propia plataforma; reutiliza uno existente solo si coinciden URL de callback, categoría y proyecto, y nunca sobrescribe en silencio otro en la misma dirección.
• Proyecto. En el plugin no se elige: se vincula el proyecto que esté abierto en el panel, y en todo el flujo no hay un segundo selector.

El argumento del ahorro de tiempo se responde solo. Un paquete por comercio compra una instalación más corta a cambio de un secreto en un fichero; la tienda conectada así tampoco configuró nada, y su fichero sigue vacío.

¿Por qué sirve el mismo archivo para todos los comercios?

El mismo archivo sirve para todos porque un plugin es código, y dentro del código no hay ninguna cuenta. Los ecosistemas de CMS parten justo de eso, y sus reglas de distribución están escritas alrededor de esa suposición.

WordPress lo deja por escrito como norma del directorio: «The only version of the plugin that WordPress.org distributes is the one in the directory». Un artefacto por versión, servido a todo el mundo, es la forma en la que un CMS espera recibir un plugin, venga por el canal que venga.

Un paquete por comercio no encaja en ningún canal de esos. No se puede publicar como versión, ni contrastar con una pública, ni comparar entre versiones, sencillamente porque no existe esa única versión publicada con la que compararlo.

Paymos reparte sus ocho plugins oficiales como descargas públicas: un paquete por plataforma y por versión. Cada versión deja un solo archivo para WooCommerce y WHMCS, OpenCart y PrestaShop, Magento 2 y Shopware 6, CS-Cart y Easy Digital Downloads.

¿Qué te permite un paquete sin credenciales?

Un paquete sin credenciales evita que tres operaciones corrientes se conviertan en filtraciones: pasar el fichero, rotar una clave y sustituir el plugin. Las tres caben en una semana normal de trabajo.

Pasarle el fichero a un desarrollador, a una agencia o a un compañero no revela nada: el archivo de Paymos ya lo tienen todos los demás. Lo que se mueve no es el objeto que da acceso.

Rotar una credencial no exige descargar nada nuevo. La clave y el archivo son objetos distintos, así que volver a conectar la tienda es todo el procedimiento tras una rotación; en el secreto de webhook hay además un margen que acepta firmas del actual y del anterior.

OWASP coloca la rotación en el mismo sitio: «You should regularly rotate secrets so that any stolen credentials will only work for a short time». Una rotación que empieza por volver a descargar el plugin se aplaza, y sustituir el archivo sigue siendo una operación de código: ahí dentro no hay ningún secreto que mudar.

¿Hasta dónde llega la credencial que acaba dentro?

La credencial que llega a un CMS debería ser la más estrecha que haga el trabajo. Una tienda es una máquina compartida, y la carpeta de plugins la lee cualquiera que tenga acceso de administrador.

La conexión emite una credencial Payment, y Payment y Payout van separadas: un plugin de cobro nunca tiene en la mano la que saca el dinero. Sandbox y Producción funcionan con credenciales distintas contra el mismo contrato de API, de modo que la clave con la que pruebas no es la que acepta pagos reales.

Una credencial de Paymos admite una lista de hasta 50 direcciones IP permitidas, lo que la ata a las que usa la tienda. Una copia presentada desde otro sitio se rechaza, así que una clave sacada de una copia de seguridad deja de funcionar.

La Merchant API se autentica firmando cada petición con HMAC-SHA256 y no con un token al portador: el secreto firma la petición en lugar de viajar dentro de ella. El modelo completo está en claves de API.

¿Qué no demuestra un archivo vacío?

Un archivo sin credenciales demuestra una sola cosa: el fichero no llevaba ningún secreto. Como revisión de seguridad es una afirmación estrecha, porque deja dos preguntas abiertas y las dos pesan más que la que acaba de responder.

La primera es el almacenamiento. En cuanto una credencial llega a la tienda, algo tiene que guardarla ahí, y cómo lo hace es una propiedad aparte con su propia respuesta: los plugins de Paymos guardan esos valores cifrados del lado de la tienda, no los devuelven al navegador y no ofrecen ninguna forma de cambiarlos a mano.

La segunda es lo que ocurre en marcha. Un archivo es una foto fija del código, así que leerlo cuenta lo que un plugin puede hacer, no lo que hace en una tienda por la que pasan facturas reales.

Las dos merecen respuesta, y una suma de verificación no cierra ninguna. Revisar el archivo es la parte barata: unos minutos que quitan de en medio una clase entera de filtración antes de instalar nada.

¿Qué preguntar antes de instalar un plugin de pagos?

Cuatro preguntas resuelven cómo trata las credenciales un plugin de pagos, y las cuatro se responden antes de instalarlo.

1. ¿El archivo es el mismo para todos? Calcula el hash de tu descarga, bájala desde otro ordenador y compara.
2. ¿Hay algún valor vivo dentro? Busca en los ficheros descomprimidos: nombres de campo y plantillas no son hallazgos.
3. ¿Dónde deja el plugin la credencial una vez instalado? Eso va en la documentación, no en una respuesta de soporte.
4. ¿Hasta dónde llega la clave que sostiene? Un plugin de cobro con permisos de retiro lleva más de lo necesario.

Ninguna es una auditoría de seguridad. Juntas descartan el fallo sin paso de recuperación: un secreto ya copiado a un sitio del que nadie llevó la cuenta.

Un plugin es una de las rutas que llevan de una tienda al cobro. Las demás están al lado, y una integración propia contra la API REST es el caso sin archivo que revisar. Vaya por donde vaya la tienda, su credencial debería empezar ahí y no en un fichero que ya viajó.