Guías Guía

Cómo autoauditar tu tienda PrestaShop — Módulo gratuito Security Scan

Revisa tu tienda PrestaShop en busca de módulos vulnerables, archivos expuestos y señales de malware con un escaneo local privado dentro de tu tienda.

Consigue el módulo gratuito Security Scan Se ejecuta dentro de tu propia tienda. Informe privado de 0 a 100 con pasos de corrección manuales. No se nos envía nada.

Dos formas de revisar tu tienda

Para una lectura rápida en segundos, usa nuestro Security Scanner público: introduce la URL de tu tienda y detecta de forma pasiva tus versiones de PrestaShop y PHP, comprueba si esa versión está expuesta públicamente o al final de su vida útil, e inspecciona tus cabeceras de seguridad HTTPS — sin instalación, sin nada que configurar. Solo lee lo que cualquier visitante ya ve.

Ese es también su límite. Un chequeo público no puede decir qué versiones de módulos usas realmente, cuáles son los permisos de tus archivos, si el modo debug está activo o si una copia de seguridad .sql está tirada en tu webroot — y esa última categoría es la causa de la mayoría de los hackeos de tiendas PrestaShop. Para eso, instala el módulo gratuito Security Scan: escanea tu tienda desde dentro, donde el consentimiento viene de serie, porque la tienda es tuya. Esta guía te muestra cómo ejecutarlo, cómo leer el informe y — con comandos reales — cómo corregir lo que encuentre. Como referencia profunda de endurecimiento, nuestra checklist de endurecimiento de seguridad de PrestaShop va más allá.

Qué comprueba un escaneo local

El informe está agrupado por áreas — primero las comprobaciones confirmadas (versiones, archivos expuestos), después las heurísticas (malware y código), claramente señaladas. Cada hallazgo te dice qué se encontró, por qué importa y cómo corregirlo.

GrupoQué examina
Versiones & vulnerabilidades conocidasTu núcleo de PrestaShop, cada módulo instalado y PHP, contrastados con una lista curada de avisos de seguridad (alimentada por la célula de seguridad de Friends of Presta). Señala versiones EOL y módulos con CVE publicados.
Archivos & endpoints expuestosCosas que nunca deberían ser accesibles desde la web — confirmadas contra tus propias URL públicas: .git, copias de seguridad .sql/.zip, /install, phpinfo, listado de directorios, .htaccess débil, carpetas con escritura para todos, parameters.php legible.
Malware & integridad (heurístico)Firmas de web shells / loaders inyectados y archivos PHP escondidos en las carpetas de imágenes.
Escaneo estático del código (heurístico)Patrones en el código de los módulos que pueden indicar un manejo inseguro de las entradas — señalados en privado para tu revisión, nunca como acusación pública.
Endurecimiento & configuraciónSSL forzado en todas partes, flags de cookies seguras, protección de la carpeta de administración, token CSRF, bloqueo antifuerza bruta, módulos obsoletos, cuentas de administrador creadas recientemente.

Los grupos de malware y código son heurísticos a propósito — conjeturas fundadas que de vez en cuando señalarán algo inofensivo. Preferimos mostrarte un falso positivo que puedes descartar en diez segundos antes que pasar por alto silenciosamente una web shell.

Cada hallazgo es verificable. Cada coincidencia de versión y de CVE enlaza directamente con el aviso oficial — el registro CVE o el GitHub Security Advisory del fabricante — y lleva un nivel de confianza, para que puedas comprobar cada señalización tú mismo en lugar de fiarte de nuestra palabra. Donde el escáner solo puede inferir algo, o no puede confirmar un ajuste desde fuera, lo dice con claridad y le asigna una puntuación baja. Está construido para ser preciso, no alarmista.

Cómo ejecutarlo

Instala y activa el módulo gratuito Security Scan, luego abre Configurar → Security Scan → Scan & Report y haz clic en Run scan now. Un escaneo típico tarda unos segundos. Las comprobaciones solo leen los archivos, la configuración y la base de datos de tu tienda además de tus propias URL públicas; el módulo únicamente escribe su propio registro en el historial de escaneos, por lo que nunca modifica archivos de la tienda, ajustes, productos, pedidos ni clientes — seguro en una tienda en producción.

¿Prefieres la línea de comandos, o automatizarlo? Puedes lanzar el mismo escaneo local desde un contexto PrestaShop arrancado (la salvaguarda impide que se ejecute vía web si te dejas el archivo olvidado):

<?php
// scan-now.php — run from the CLI only; delete the file if you place it in the shop root
if (PHP_SAPI !== 'cli') {
    http_response_code(403);
    exit;
}

require __DIR__ . '/config/config.inc.php';
require __DIR__ . '/modules/mprsecurityscan/vendor/autoload.php';

$run = \MPRSecurityScan\Service\ScanRunner::runAndStore('manual');
printf("Score %d/100 (grade %s) — %d issues\n",
    $run['result']['score'], $run['result']['grade'], $run['result']['problem_count']);

Cómo leer tu puntuación

El informe de Security Scan: una puntuación de seguridad de 0 a 100 con calificación por letra, fichas con recuentos por gravedad y hallazgos agrupados por gravedad con pasos de corrección
La pantalla Scan & Report: tu puntuación y calificación, un desglose por gravedad y cada hallazgo con sus pasos de corrección manuales.

Obtienes un único número sobre 100 y una calificación por letra. La puntuación empieza en 100 y pierde puntos por cada problema real, ponderado por gravedad — un problema crítico cuesta mucho más que uno leve. También se muestran las comprobaciones superadas, para que veas qué se verificó realmente.

  • Crítico −30 cada uno — explotable ahora mismo, o una exposición confirmada. Corrígelo hoy.
  • Alto −15 — serio; corrígelo esta semana.
  • Medio −7 — carencias relevantes de endurecimiento o de higiene.
  • Bajo −3 — mejoras menores.

Todo eso se condensa en una calificación — A 90+, B 75+, C 60+, D 40+, F por debajo de 40. Trata la puntuación como una herramienta de priorización, no como una garantía: una puntuación alta significa que el escáner no encontró problemas conocidos en lo que puede ver.

Ejemplo práctico: un directorio .git expuesto

Es uno de los hallazgos más comunes — y más peligrosos. Si desplegaste con git clone o git pull en tu webroot, toda la carpeta .git (con el historial completo de tu código y cualquier secreto que alguna vez se haya commiteado) puede ser descargable. El escáner lo confirma solicitando realmente /.git/HEAD por HTTP y comprobando que la respuesta parece metadatos de un VCS.

Crítico — los metadatos del VCS son accesibles públicamente. El escáner confirmó que /.git/HEAD devuelve metadatos de VCS por HTTP.

Corrígelo en dos pasos. Primero, desde la raíz de tu tienda, haz copia de seguridad de los metadatos y elimínalos (las salvaguardas garantizan que no se borra nada a menos que la copia haya tenido éxito):

# run from your shop root
set -eu

paths=()
[ -d .git ] && paths+=(.git)
[ -d .svn ] && paths+=(.svn)

if [ "${#paths[@]}" -gt 0 ]; then
  tar czf "$HOME/vcs-metadata-backup-$(date +%F-%H%M%S).tgz" "${paths[@]}"
  rm -rf "${paths[@]}"
fi

Después asegúrate de que el servidor web rechace los directorios que empiezan por punto, aunque alguno reaparezca. Apache (.htaccess o vhost) — esto deniega los archivos con punto y las rutas de directorios con punto como /.git/HEAD, conservando /.well-known/:

<FilesMatch "^\.">
  Require all denied
</FilesMatch>

RedirectMatch 404 "(^|/)\.(?!well-known(?:/|$))"

O nginx:

location ^~ /.well-known/ {
    try_files $uri =404;
}

location ~ /\.(?!well-known(?:/|$)) {
    return 404;
}

Vuelve a ejecutar el escaneo; el hallazgo debería desaparecer (la URL ahora devuelve 403/404). Si algún secreto vivió alguna vez en ese historial, rótalo.

Qué corregir primero (con los comandos)

Trabaja el informe de arriba abajo. Aquí tienes las correcciones para los hallazgos que verás más a menudo.

Archivos de copia de seguridad en la webroot

Un store.sql o un backup.zip junto a index.php es una copia completa de tu tienda, a una simple adivinanza de distancia. Lístalos y luego mueve cada coincidencia fuera del docroot (mv -n nunca sobrescribe):

# review the list first
find . -maxdepth 2 -type f \
  \( -name '*.sql' -o -name '*.sql.gz' -o -name '*.zip' -o -name '*.tar.gz' -o -name '*.bak' \) -ls

# then move every match out of the webroot
mkdir -p "$HOME/private-backups"
find . -maxdepth 2 -type f \
  \( -name '*.sql' -o -name '*.sql.gz' -o -name '*.zip' -o -name '*.tar.gz' -o -name '*.bak' \) \
  -exec mv -n -- {} "$HOME/private-backups/" \;

Directorio /install olvidado

PrestaShop te indica eliminarlo tras la instalación. En lugar de borrarlo sin más, ponlo en cuarentena (ejecútalo desde la raíz de tu tienda):

# run from your shop root
set -eu
test -f config/config.inc.php

backup="$HOME/prestashop-install-dirs-$(date +%F-%H%M%S)"
mkdir -p "$backup"
[ -d install ] && mv install "$backup/"
[ -d install-dev ] && mv install-dev "$backup/"

Modo debug dejado activo

El modo desarrollador filtra stack traces y rutas a los visitantes. Edita la línea existente en config/defines.inc.php (o config/defines_custom.inc.php) — no añadas una segunda debajo:

<?php
// change the EXISTING _PS_MODE_DEV_ line to false (never true on a live shop)
define('_PS_MODE_DEV_', false);

Carpetas con escritura para todos (0777)

El escáner señala los directorios en 0777. Restaura permisos de privilegio mínimo — nunca chmod 777, y mantén ilegibles los archivos de configuración secretos (un parameters.php legible por todos ya es en sí un hallazgo). Ejecútalo desde la raíz de tu tienda:

# run from your shop root; set these to your real PHP-FPM/web user + group
WEB_USER=www-data
WEB_GROUP=www-data

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

# lock down the secret config files: owned by the web user, readable by owner+group only
# (never world-readable — but still readable by the PHP process). Adjust owner/group above.
for f in app/config/parameters.php config/settings.inc.php; do
  [ -f "$f" ] || continue
  chown "$WEB_USER:$WEB_GROUP" "$f"
  chmod 640 "$f"
done

# only the writable dirs need to be owned by the web user
for dir in var/cache var/logs img upload download; do
  [ -d "$dir" ] || continue
  chown -R "$WEB_USER:$WEB_GROUP" "$dir"
  find "$dir" -type d -exec chmod 775 {} \;
  find "$dir" -type f -exec chmod 664 {} \;
done

.htaccess débil o ausente

Regenera las reglas protectoras de PrestaShop desde el Back Office (Parámetros de la tienda → Tráfico & SEO → Regenerar el archivo .htaccess), y luego confirma que los archivos sensibles están bloqueados y que el listado de directorios está desactivado. Una protección mínima:

<FilesMatch "(?i)(parameters\.php|settings\.inc\.php|\.env|composer\.(json|lock))$">
  Require all denied
</FilesMatch>

Options -Indexes

Los límites de la detección sola

Ser honestos sobre los límites forma parte de usar bien cualquier herramienta de seguridad: detecta problemas, no los corrige por ti; las comprobaciones heurísticas pueden señalar cosas inofensivas (verifica antes de borrar); la cobertura de avisos es curada, no exhaustiva; y no es un test de penetración. Para la referencia completa de remediación — endurecimiento del servidor, blindaje del admin, base de datos y monitorización — sigue la checklist de endurecimiento de seguridad.

Cuándo dejar de escanear y pedir ayuda

Algunos hallazgos significan que toca una persona, no una herramienta. Archivos con pinta de malware, cualquier cosa que parezca un skimmer de pagos, cuentas de administrador que no reconoces, credenciales expuestas o reinfecciones repetidas — eso es un incidente. Si prefieres dejarlo en nuestras manos, reserva una auditoría de seguridad.

Cuándo tienen sentido las correcciones automáticas

El escáner gratuito es deliberadamente de un solo uso: lo ejecutas, lo lees y corriges las cosas a mano. Perfecto para una revisión ocasional. Si prefieres no hacerlo manualmente — o quieres seguir protegido — Security Revolution aplica correcciones con un clic, endurece tu tienda, monitoriza la integridad de los archivos del núcleo, te avisa cuando algo cambia y gestiona toda una flota de tiendas desde un solo panel. Los mismos hallazgos; simplemente actúa sobre ellos y sigue vigilando.

FAQ

¿El escaneo envía mis datos a algún sitio? Para un escaneo independiente desde el panel o la CLI, no — el informe se queda en tu servidor, y las únicas peticiones salientes son autocomprobaciones hacia tus propias URL públicas, protegidas contra el acceso a direcciones internas (SSRF). Si activas explícitamente el conector de flota opcional, los resultados de los escaneos se envían — por un canal firmado — al hub que hayas configurado.

¿Corrige los problemas automáticamente? No — este módulo es solo de detección. Las correcciones automáticas y la monitorización están en Security Revolution.

¿Es seguro en una tienda en producción? Sí. Lee tus archivos, configuración y base de datos y solo escribe su propio registro en el historial de escaneos — nunca modifica contenido de la tienda, ajustes, productos, pedidos ni clientes.

¿Con qué frecuencia debería escanear? Después de cada actualización de PrestaShop o de un módulo, y al menos una vez al mes. La página Historial sigue tu puntuación a lo largo del tiempo.

¿Puede sustituir a un desarrollador? No. Es una primera pasada rápida y útil que atrapa los riesgos comunes y bien conocidos. Las auditorías profundas y los incidentes reales siguen necesitando a un humano.

Lecturas relacionadas

Cargando...
Volver arriba