La tarjeta de evaluación de riesgo de módulos: 12 comprobaciones antes de instalar

No necesita saber leer PHP para determinar si un módulo de PrestaShop es seguro para instalarlo en su tienda en producción. La mayor parte del daño que causa un mal módulo es visible desde un navegador y desde su back office, si sabe dónde mirar. Esta es la lista de comprobación que usamos nosotros, redactada para que el propietario de una tienda pueda aplicarla sin un desarrollador.

La idea es sencilla. Un módulo es código sin aislamiento (sin sandbox) que se ejecuta con todos los privilegios de su tienda: puede cargar recursos en cada página, escribir en su base de datos, modificar el comportamiento del núcleo y hacer llamadas a otros servidores. Así que, en lugar de fiarse de la página de venta, usted observa lo que el módulo realmente hace en una copia segura de su tienda y lo puntúa. Diez comprobaciones en verde de doce es un módulo que puede instalar con confianza. Pero la puntuación no lo es todo: algunas filas son motivos de rechazo absoluto. Una señal de alarma en el checkout o en los datos de clientes, en la prueba de reversibilidad, en un nuevo dominio externo o en overrides no declarados significa que el módulo no entra en su tienda en producción hasta que el proveedor lo explique, digan lo que digan las demás filas.

Ejecute esto primero en una copia de staging, nunca en producción. Duplique su tienda (la mayoría de los alojamientos ofrecen un clon de staging con un solo clic) o utilice una instalación desechable con su plantilla y sus demás módulos presentes. Conviene que el módulo se enfrente a la misma realidad desordenada que su tienda real: su plantilla, su configuración de idioma y moneda, sus módulos existentes, sus versiones de PrestaShop y de PHP. Un módulo que solo se comporta bien en una instalación en blanco le está diciendo algo.

Las doce comprobaciones

1. Dominios externos y CDN

Cómo ejecutarla: abra la página de inicio de su tienda —no la página de configuración del módulo— en su navegador, pulse F12 para abrir las Herramientas de desarrollo, haga clic en la pestaña Red (Network) y recargue la página. Ordene por Dominio. Anote cada dominio que no sea el suyo. Ahora instale el módulo y recargue de nuevo. ¿Apareció algún nuevo dominio de terceros?

Aprobado: ningún dominio externo nuevo en páginas que no usan la funcionalidad. Modo de fallo: esta es exactamente la trampa de nuestro ensayo: un módulo que carga una fuente, un script o un rastreador desde el servidor de otra persona en cada página, añadiendo resoluciones DNS, peso, una exposición de privacidad y una dependencia de un servidor que usted no controla. Si ese servidor está lento o caído algún día, la representación de su escaparate puede detenerse o degradarse con él.

Si prefiere contarlos con exactitud en lugar de leer la lista a ojo, pegue esto en la misma pestaña Consola (Console) de las Herramientas de desarrollo y pulse Intro: enumera cada dominio que no sea el suyo y cuántas peticiones hizo cada uno:

// On your homepage: reload the page first, then paste this into DevTools → Console.
const here = location.host;
const thirdParty = {};
for (const r of performance.getEntriesByType('resource')) {
    const host = new URL(r.name).host;
    if (host && host !== here) {
        thirdParty[host] = (thirdParty[host] || 0) + 1;
    }
}
console.table(thirdParty); // each row is an external host your page called

Cuenta cada host que no sea su dominio principal, incluidos los subdominios de CDN que usted mismo gestione, que puede ignorar sin problema. Ejecútelo antes de instalar el módulo y de nuevo después: cualquier host genuinamente nuevo es un nuevo tercero del que ahora depende su escaparate.

Esta es la comprobación de mayor valor de la lista, porque detecta exactamente el fallo de nuestro ensayo: un módulo que añade sigilosamente un dominio de terceros a cada página. Si aquí aparece un host que usted no añadió a propósito, deténgase y pregunte al proveedor por qué antes de que llegue nunca a su tienda en producción.

2. Recursos globales del front office

Cómo ejecutarla: en la misma pestaña Red, filtre por CSS y JS y compare el recuento en su página de inicio antes y después de instalar. Luego compruebe una página a la que el módulo debería afectar y una a la que no debería.

Aprobado: las hojas de estilo y los scripts del módulo se cargan solo en las páginas que los usan. Modo de fallo: un módulo «pequeño» que registra sus recursos en un hook de cabecera global añade peso a cada página de la tienda, incluido el checkout, por una funcionalidad que vive en una sola. Multiplique eso por una docena de módulos descuidados y tendrá una tienda lenta sin un único culpable.

3. Overrides

Cómo ejecutarla: antes de instalar, mire en la carpeta /override de su tienda por FTP o con el gestor de archivos de su alojamiento (solo comprueba si aparecen archivos; no necesita leerlos). Instale el módulo y vuelva a mirar.

Aprobado: no apareció ningún archivo nuevo en /override (una carpeta de serie ya contiene archivos index.php de marcador de posición; usted busca los nuevos). Modo de fallo: los overrides viven en /override y cambian cómo se comportan las clases y los controladores del núcleo de PrestaShop. Dos módulos que hacen override de la misma clase entran en conflicto y —lo que es crítico— un override que queda tras desinstalar es una de las causas principales de «mi tienda se rompió y desactivar cosas no lo arregló». Los buenos módulos usan hooks y servicios en lugar de hacer override del núcleo.

4. Hooks utilizados

Cómo ejecutarla: en el back office, vaya a Diseño › Posiciones (la pantalla de hooks) y observe dónde se registró el módulo. También suele poder ver los hooks de un módulo en su página de configuración.

Aprobado: los hooks coinciden con la funcionalidad. Un módulo de envíos se engancha en el envío y el checkout; un módulo de pestañas de producto se engancha en la página de producto. Modo de fallo: un módulo enganchado en todas las páginas —displayHeader, displayFooter en todo— «por si acaso», cuando su funcionalidad solo aparece en un lugar. Cada uno de esos hooks es código que se ejecuta en cada carga de página.

5. Cambios en el esquema de la base de datos

Cómo ejecutarla: en la herramienta de base de datos de su alojamiento (phpMyAdmin o similar), anote el número de tablas antes de instalar. Instale y observe lo que se añadió: comprueba nombres, no contenidos.

Aprobado: las nuevas tablas están claramente asociadas a un espacio de nombres del módulo (un prefijo reconocible) e, idealmente, documentadas. Un puñado de tablas con buenos nombres es completamente normal y correcto. Modo de fallo: un módulo que dispersa tablas sin etiquetar, o escribe en las tablas del núcleo de PrestaShop de formas que no declara, es uno sobre el que no podrá razonar con limpieza más adelante.

Si tiene acceso a la base de datos (phpMyAdmin o la línea de comandos), puede listar exactamente qué añadió un módulo. Anote la lista antes de instalar, luego ejecútela de nuevo después y compare:

-- Note the list before installing, then run it again afterwards and compare.
SHOW TABLES;

-- Most well-built modules prefix their own tables — list them (base table + children):
SHOW TABLES LIKE 'ps\_mymodule%';

Una lista corta y con un prefijo claro es saludable. Una dispersión de tablas sin etiquetar —o escrituras no declaradas en tablas del núcleo como ps_orders o ps_customer— es lo que hay que vigilar. (ps_ es el prefijo de tabla por defecto; sustitúyalo por el suyo si lo cambió, y use el nombre técnico del módulo en lugar de mymodule.)

6. Limpieza al desinstalar

Cómo ejecutarla: tras su comprobación del esquema, desinstale el módulo y mire de nuevo la base de datos. ¿Qué eliminó y qué dejó?

Aprobado: el módulo elimina lo que creó, o indica claramente en su documentación qué conserva deliberadamente y por qué (conservar sus ajustes para una futura reinstalación es una elección legítima, si se declara). Modo de fallo: restos silenciosos. Tablas huérfanas, filas de configuración y archivos obsoletos que se acumulan cada vez que prueba un módulo. Esta es la fila en la que «ya lo desinstalaré» falla en silencio.

7. Tareas cron y webhooks

Cómo ejecutarla: revise la documentación y la página de configuración del módulo en busca de cualquier cosa que se ejecute de forma programada o que llame a un servicio externo en segundo plano: sincronizaciones, feeds, tareas de limpieza, integraciones de «conecte su cuenta».

Aprobado: las tareas en segundo plano están declaradas y puede desactivarlas. Modo de fallo: actividad en segundo plano no declarada: una tarea machacando su base de datos según un calendario, o un webhook enviando sus datos a algún sitio del que no era consciente. No puede gestionar lo que no sabe que se está ejecutando.

8. Puntos de contacto con checkout, pedidos y datos de clientes

Cómo ejecutarla: con el módulo instalado en staging, realice un pedido de prueba completo de principio a fin. Busque un producto. Abra una página de producto. Abra las pantallas principales del back office. ¿Sigue funcionando todo exactamente como antes?

Aprobado: el checkout, la búsqueda, las páginas de producto y la administración no se ven afectados salvo que ese sea literalmente el cometido del módulo. Modo de fallo: un módulo que toca el flujo de pedidos o los registros de clientes está tocando sus ingresos y sus obligaciones de cumplimiento. Un checkout que se rompe —o que calcula mal en silencio— le cuesta dinero real el día que se publica, no en un laboratorio.

9. Multitienda, idioma y moneda

Cómo ejecutarla: si gestiona más de una tienda, más de un idioma o más de una moneda, pruebe el módulo en cada uno. Cambie de tienda, cambie de idioma, cambie de moneda y use la funcionalidad.

Aprobado: el módulo respeta su configuración: correcto por tienda, traducido por idioma, importes correctos por moneda. Modo de fallo: un módulo construido y probado contra «tienda 1, inglés, euros» que fija esas suposiciones en el código. Se ve bien en la demo y se desmorona en su segundo escaparate o en los precios de sus clientes polacos.

10. Compatibilidad con PrestaShop y PHP

Cómo ejecutarla: lea la declaración de compatibilidad en la página del producto y contrástela con su versión de PrestaShop (1.7, 8.x o 9.x) y su versión de PHP.

Aprobado: el proveedor nombra las versiones exactas que el módulo admite y las mantiene al día a medida que PrestaShop publica nuevas versiones. Modo de fallo: «compatible con todas las versiones». Ningún módulo serio se prueba contra cada versión de PrestaShop y de PHP jamás publicada; esa afirmación es marketing, y es la fila con más probabilidades de romperse el día que actualice su tienda.

11. Registro de cambios y rastro de soporte

Cómo ejecutarla: busque un registro de cambios con fechas y un canal de soporte real antes de comprar.

Aprobado: el módulo tiene un historial visible de actualizaciones y una forma de contactar con una persona que lo mantiene. Modo de fallo: sin registro de cambios y sin soporte significa sin dueño. Un módulo sin mantenimiento es un módulo que tarde o temprano dejará de funcionar con una actualización de PrestaShop o de PHP, sin nadie que lo arregle, y se enterará en el peor momento posible.

12. La prueba de reversibilidad

Cómo ejecutarla: esta es toda la lista de comprobación en un solo movimiento, en staging. Haga una instantánea de su tienda. Instale el módulo. Desactívelo. Desinstálelo. Compare la tienda con su instantánea.

Aprobado: instalar → desactivar → desinstalar deja la tienda esencialmente como estaba: sin archivos residuales, sin tablas huérfanas, sin páginas rotas. Modo de fallo: cualquier cosa que no vuelva a su estado. Si un módulo no se puede eliminar con limpieza en una copia de prueba, desde luego no se podrá eliminar con limpieza de su tienda en producción bajo presión.

Señales de alarma, y lo que realmente significa cada una

No siempre tendrá tiempo para las doce completas. Estos son los atajos: señales que, por sí solas, justifican una mirada mucho más atenta. Cada una se corresponde con una forma concreta en que las cosas salen mal:

Ninguna de estas es prueba de que un módulo sea malo. El código barato y sencillo puede ser perfectamente bueno; un proveedor pequeño puede ser excelente. El problema nunca es el precio ni el autor: es el riesgo no gestionado. Una señal de alarma solo significa que el riesgo no se ha gestionado por usted, así que tiene que gestionarlo usted mismo antes de que llegue a su tienda en producción.

Dónde encajan los estándares oficiales

La propia PrestaShop publica las reglas técnicas que se supone que sigue un módulo bien construido. No necesita implementarlas, pero son útiles para señalárselas a un proveedor, y coinciden con buena parte de lo anterior. PrestaShop publica los Estándares Técnicos de Desarrollo que se espera que siga un módulo bien construido —disciplina con los overrides, higiene de las tablas del núcleo y del rendimiento de los recursos, seguridad y compatibilidad de versiones— junto con los Estándares de Calidad detrás de la insignia Verified+ en el marketplace de Addons. Ninguno es una garantía por sí solo —muchos buenos módulos viven fuera del marketplace, y una insignia no sustituye las observaciones anteriores— pero forman una parte sensata del cuadro. Si compra a través del marketplace, nuestra guía del comprador de PrestaShop Addons explica cómo leer una ficha.

Un orden de instalación seguro, de principio a fin

En conjunto, todo esto es una única secuencia tranquila:

• Haga una copia de seguridad de su tienda en producción: archivos y base de datos.
• Instale en una copia de staging que refleje su plantilla, módulos y ajustes reales.
• Haga una instantánea de la tienda de staging y luego ejecute las doce comprobaciones anteriores.
• Vigile la pestaña Red en su página de inicio en busca de dominios nuevos y recursos cargados en todo el sitio.
• Realice un pedido de prueba y ejercite la búsqueda, las páginas de producto y la administración.
• Desinstale y compare con su instantánea: confirme que vuelve limpia a su estado.
• Solo entonces instale en producción, en una franja horaria tranquila, y compruebe sus páginas clave una vez más.

Preguntas frecuentes

¿Necesito un desarrollador para evaluar un módulo?

Para la mayoría de estas comprobaciones, no. Contar las peticiones de terceros, probar el checkout y ejecutar la prueba de instalar → desactivar → desinstalar son cosas que puede hacer desde un navegador y su back office en una copia de staging. Un par de comprobaciones —mirar en /override, listar las tablas de la base de datos— necesitan acceso a archivos o a la base de datos, que su alojamiento o desarrollador puede facilitarle, pero nunca tiene que leer código.

Si un módulo está en el marketplace oficial de PrestaShop, ¿es automáticamente seguro?

La validación del marketplace y la insignia Verified+ son una señal real y útil: comprueban muchas de estas cosas por usted. Pero no sustituyen a observar el módulo comportarse en su propia tienda, con su plantilla y sus demás módulos. Muchos buenos módulos también viven fuera del marketplace. Ejecute las comprobaciones en cualquier caso.

El módulo es gratuito. ¿Es eso una señal de alarma por sí sola?

No. Los módulos gratuitos y baratos pueden ser excelentes, y los caros pueden ser descuidados. El precio no le dice nada sobre cómo se comporta el código. La tarjeta de puntuación trata del riesgo gestionado, no del coste: un módulo gratuito que pasa estas comprobaciones es más seguro que uno de pago que las suspende.

Si solo tengo tiempo para una comprobación, ¿cuál es?

Abra la pestaña Red de su página de inicio y cuente los nuevos dominios de terceros tras instalar. Lleva un minuto, no necesita código y detecta el tipo más común y más dañino de módulo descuidado: el que grava cada página por una funcionalidad que rara vez verá.

Escrito así parece mucho; en la práctica es una tarde, y sale mucho más barato que la tarde que de otro modo pasaría averiguando por qué se volvió lenta su tienda, o por qué una página no vuelve a funcionar después de quitar el módulo que la rompió. Para conocer la historia de por qué esto importa —y un relato honesto de un error que cometimos nosotros mismos— lea lo que un módulo de PrestaShop puede hacer que desinstalarlo no deshará. Y sí: ejecute esta lista de comprobación también contra nuestros módulos. Para eso está. Si quiere que se la ejecutemos nosotros, nuestro análisis de seguridad gratuito y nuestra auditoría de rendimiento se basan exactamente en estas comprobaciones, y si prefiere que su tienda vigile estas cosas de forma continua en lugar de solo en el momento de la instalación, ese es el cometido de Performance Revolution y Security Revolution.