Seguridad en tu tienda PrestaShop: Guía práctica para propietarios

Gestionar una tienda online implica manejar dinero real y datos reales de clientes. Eso te convierte en un objetivo — no porque seas especialmente interesante, sino porque bots automatizados rastrean constantemente cada instalación de WordPress, Magento y PrestaShop en internet buscando vulnerabilidades conocidas. La buena noticia: la mayoría de los ataques tienen éxito por errores básicos, y los errores básicos tienen solución. Esta guía cubre lo que realmente importa, en el orden en que realmente importa.

SSL: lo tienes, pero ¿está funcionando correctamente?

Hoy en día todas las tiendas tienen certificado SSL. La mayoría lo tienen mal configurado. El candado en el navegador solo significa que la página en sí se cargó por HTTPS — no que toda tu tienda esté cifrada. El problema oculto es el contenido mixto: imágenes, scripts u hojas de estilo que se cargan por HTTP plano en una página HTTPS. Los navegadores los bloquean silenciosamente, rompiendo funcionalidades sin mensajes de error evidentes.

Abre Chrome DevTools en tu página de inicio, ve a Consola y busca avisos de "Mixed Content". Corrígelos actualizando las URLs http:// codificadas directamente en tu tema, módulos o configuración de la base de datos. En PrestaShop, comprueba en Parámetros de la tienda → General que tanto el dominio de la tienda como el dominio SSL apunten a tu URL HTTPS.

Verifica también que la redirección de HTTP a HTTPS funcione a nivel servidor, no solo dentro de PrestaShop. Si alguien visita http://yourstore.com, debe recibir una redirección 301 a https://yourstore.com antes de que PrestaShop siquiera se cargue. Revisa tu .htaccess — la regla de redirección debe estar antes que las reglas de reescritura de PrestaShop, no enterrada dentro de ellas.

Tu URL de administración es de dominio público

Toda instalación estándar de PrestaShop coloca el panel de administración en /admin seguido de un sufijo aleatorio generado durante la instalación. Ese sufijo no es una medida de seguridad — es solo una pequeña molestia. Los bots prueban patrones comunes sistemáticamente. Tu URL de administración no está tan oculta como crees.

Renombra el directorio de administración a algo que no contenga la palabra "admin". Elige algo sin significado — evita palabras del diccionario por completo. Esto no detendrá a un atacante decidido con acceso a tus archivos, pero elimina de inmediato el escaneo automatizado masivo.

Si tu hosting admite listas blancas de IP mediante .htaccess, úsalas. Añade una directiva Require ip dentro del .htaccess de tu carpeta de administración para permitir solo las IPs de tu oficina y de casa. Sí, es incómodo cuando viajas. Sí, merece la pena.

Cuentas de empleados: una persona, una cuenta, sin excepciones

Las cuentas de administración compartidas son una de las causas más comunes de incidentes de seguridad — y las más difíciles de investigar después. Cuando todos los empleados se conectan como "admin", no hay rastro de auditoría. No puedes saber quién eliminó un producto, quién cambió un precio o quién exportó la lista de clientes a las 2 de la madrugada.

Crea cuentas individuales para cada persona que necesite acceso al back-office. Usa correctamente los perfiles de permisos de PrestaShop: un agente de atención al cliente no necesita acceso a la configuración de pagos. Un operador de almacén no necesita acceso a la gestión de empleados. El principio de mínimo privilegio no es burocracia — limita el daño cuando una cuenta se ve comprometida.

Audita tu lista de empleados trimestralmente. Elimina las cuentas de personas que ya no trabajan contigo. Los exempleados con credenciales activas son un vector de riesgo real, y es uno que controlas completamente.

Seguridad de módulos: la superficie de ataque que no estás vigilando

Los módulos son el punto de entrada más habitual para los compromisos de tiendas PrestaShop. Un módulo vulnerable — incluso uno que ya no usas activamente — puede ser explotado si está instalado y habilitado. A los atacantes no les importa que no hayas tocado ese módulo de pago en dos años. Si está ahí y es vulnerable, es una puerta abierta.

Instala módulos solo de fuentes de confianza. El marketplace PrestaShop Addons verifica las publicaciones, pero los sitios de terceros aleatorios y los repositorios de GitHub no lo hacen. Los módulos nulled — módulos de pago distribuidos ilegalmente de forma gratuita — casi siempre contienen backdoors. La lógica es simple: ¿por qué alguien regalaría software de pago? Porque le han añadido algo.

Elimina los módulos que no uses. No solo deshabilitarlos — desinstalarlos y borrar los archivos. Cada módulo instalado añade código que se carga en cada solicitud, aumentando tanto la superficie de ataque como el tiempo de carga. Haz una auditoría de módulos: si no lo has usado en seis meses y no tienes previsto hacerlo, fuera.

Actualiza tus módulos regularmente. La mayoría de las vulnerabilidades en módulos se parchean rápidamente una vez descubiertas — pero el parche solo sirve si lo instalas. Nuestro módulo Security Revolution incluye monitorización de integridad de archivos que alerta sobre cambios inesperados en los archivos de tus módulos, y nuestro módulo Total Defender añade capas de protección activa que incluyen bloqueo de bots y registro de actividad sospechosa.

Copias de seguridad de la base de datos: lo único que garantiza la recuperación

Las copias de seguridad no son una medida de seguridad — son una medida de recuperación. La distinción importa porque cambia cómo las piensas. Ninguna estrategia de copias de seguridad previene un ataque. Las buenas copias de seguridad significan que un ataque no acaba con tu negocio.

Automatiza tus copias de seguridad. Las copias manuales se saltan, se retrasan y se olvidan. Configura un cron job que exporte tu base de datos cada noche y la copie fuera del servidor. "Fuera del servidor" significa en algún lugar donde el compromiso de tu servidor web no comprometa también tus copias de seguridad — un bucket de almacenamiento en la nube separado, tu máquina local, cualquier sitio que no sea la misma máquina que podría ser borrada.

Prueba tus restauraciones. Una copia de seguridad que nunca has restaurado no es una copia de seguridad — es un archivo con contenido desconocido. Realiza una restauración de prueba en un entorno de staging al menos una vez al trimestre. No quieres que la primera vez que restaures desde una copia de seguridad sea durante un incidente real.

Mantén múltiples puntos de restauración. Copias diarias de los últimos 30 días, semanales de los últimos seis meses. Algunos ataques — especialmente la manipulación de bases de datos — no se descubren de inmediato. Necesitas poder restaurar a un punto anterior al inicio del compromiso.

Contraseñas y autenticación de dos factores

PrestaShop lleva soportando la autenticación de dos factores de forma nativa desde la versión 1.7.6. Si no la estás usando en tus cuentas de administración, actívala hoy. La configuración lleva cinco minutos. Ve a tu perfil en el back-office y activa 2FA usando una aplicación de autenticación como Google Authenticator o Authy.

Exige 2FA para todas las cuentas de administración, no solo la tuya. Un empleado con una contraseña débil y sin 2FA es el eslabón más débil de tu cadena de seguridad.

Sobre las contraseñas: usa un gestor de contraseñas y genera contraseñas largas y aleatorias para cada cuenta. "Larga" significa un mínimo de 20 caracteres para las cuentas de administración. No reutilices contraseñas entre servicios. Tu contraseña de administración de PrestaShop no debe aparecer en ningún otro sitio — ni en tu panel de hosting, ni en tu correo electrónico, ni en tu cuenta del marketplace de módulos.

Permisos de archivos: lo básico sigue siendo importante

Los permisos correctos para una instalación de PrestaShop son 755 para directorios y 644 para archivos. Si tú o tu proveedor de hosting pusisteis en algún momento los permisos a 777 "para solucionar un problema", vuelve y arréglalo correctamente. Los archivos con permisos de escritura para todos significan que cualquier proceso en el servidor — incluido código inyectado a través de una vulnerabilidad — puede modificarlos.

Comprueba específicamente los permisos de tu archivo config/settings.inc.php. Contiene las credenciales de tu base de datos. Debe tener 444 o 640 — legible por el servidor web, no modificable por nadie.

Si usas hosting compartido, tu perfil de riesgo es mayor porque compartes servidor con otros sitios. El compromiso de otro sitio en tu servidor puede afectar potencialmente al tuyo si los permisos son demasiado abiertos. Este es uno de los argumentos reales a favor de VPS frente a hosting compartido para tiendas con volumen real de transacciones.

Mantén PrestaShop y PHP actualizados

Las versiones antiguas de PHP no solo son más lentas — dejan de recibir parches de seguridad. PHP 7.4 llegó a su fin de vida en noviembre de 2022. Si tu hosting todavía lo está ejecutando (y muchos hostings compartidos aún lo hacen), estás ejecutando vulnerabilidades conocidas sin parche en el entorno de ejecución de tu servidor. Comprueba tu versión de PHP en el back-office de PrestaShop bajo Parámetros Avanzados → Información.

PrestaShop publica parches de seguridad en versiones menores. Ejecutar la 8.1.0 cuando la 8.1.7 está disponible significa que tienes agujeros de seguridad conocidos abiertos. Las actualizaciones de versión mayor requieren más cuidado, pero las actualizaciones de versión menor dentro de la misma rama son generalmente seguras y deben aplicarse rápidamente tras una copia de seguridad y una prueba en staging.

Endurecimiento del .htaccess

El .htaccess predeterminado de PrestaShop es un punto de partida, no una configuración de seguridad terminada. Añade estas reglas para bloquear el acceso directo a directorios que nunca deberían ser públicamente accesibles:

• Bloquear el acceso directo a /config/ — contiene credenciales de base de datos y claves de cifrado
• Bloquear el acceso directo a /var/ — contiene archivos de caché y logs
• Bloquear el acceso directo a /vendor/ — contiene archivos de bibliotecas de terceros
• Bloquear el acceso directo a /src/ — contiene archivos fuente del núcleo
• Bloquear la ejecución de archivos PHP dentro de /upload/ — un objetivo habitual para subidas de malware

Para el directorio de subidas específicamente, añade un .htaccess dentro de /upload/ que deniegue la ejecución de PHP. Si un atacante sube un shell PHP a través de una vulnerabilidad de subida de archivos, esta regla le impide ejecutarlo.

RGPD y seguridad de cookies

La seguridad de las cookies no es solo una cuestión de cumplimiento normativo — las cookies mal configuradas pueden exponer tokens de sesión y datos de autenticación. Asegúrate de que tus cookies de sesión estén configuradas con el flag Secure (transmitidas solo por HTTPS) y el flag HttpOnly (no accesibles para JavaScript). Si necesitas una implementación correcta del consentimiento de cookies conforme al RGPD que no rompa la funcionalidad de tu tienda, nuestro módulo Cookies Revolution lo gestiona correctamente.

Si te hackean: qué hacer realmente

Primero: no entres en pánico, pero actúa rápido. Cada hora de retraso es más daño potencial.

Aísla de inmediato. Pon tu tienda fuera de línea o en modo mantenimiento. Si tu hosting tiene una opción de "suspender sitio", úsala. Necesitas parar la hemorragia antes de diagnosticar la herida.

No borres nada todavía. El instinto será limpiar, pero necesitas preservar evidencias para entender qué ocurrió. Haz una copia de seguridad completa del estado comprometido antes de empezar a eliminar archivos.

Comprueba las fechas de modificación de archivos. Busca archivos modificados en los últimos 30 días. Compara con tu historial de despliegues. Los archivos que cambiaron sin una actualización correspondiente son indicadores de compromiso. Presta especial atención a los archivos PHP en /upload/, /img/ y los directorios de módulos — lugares donde se espera que haya escrituras de archivos y donde es más fácil ocultarlas.

Restaura desde una copia de seguridad limpia. No intentes eliminar el malware quirúrgicamente de un sitio activo — los atacantes son buenos ocultando backdoors y te perderás algo. Restaura desde una copia de seguridad que tengas la certeza de que es anterior al compromiso.

Cambia todas las contraseñas. Contraseña de la base de datos, credenciales FTP, panel de hosting, cuentas de administración de PrestaShop, cuentas de correo electrónico asociadas al dominio. Asume que todo era legible durante el período de compromiso.

Encuentra el punto de entrada. Esto es importante para evitar que se repita. Puntos de entrada comunes: un módulo vulnerable, credenciales de empleado comprometidas, una contraseña de administración forzada por fuerza bruta. Si no puedes identificar cómo ocurrió, volverá a ocurrir.

Notifica adecuadamente. Si se accedió a datos de clientes — direcciones de correo electrónico, historial de pedidos, cualquier dato de pago — probablemente tengas obligaciones legales de notificación según tu jurisdicción. El RGPD exige notificación en un plazo de 72 horas desde que se tenga conocimiento de una brecha. No lo dejes para después.

La seguridad no es una función que añades una vez y olvidas. Es mantenimiento, como mantener el contenido de tu tienda actualizado o tu inventario preciso. Programa un recordatorio trimestral para auditar cuentas de empleados, verificar actualizaciones de módulos y comprobar que tus copias de seguridad se restauran correctamente. Veinte minutos cada tres meses es mucho más barato que recuperarse de una brecha de seguridad.

Artículos Relacionados

• Seguridad de pagos en PrestaShop: PCI Compliance, 3D Secure y prevencion del fraude
• Seguridad PrestaShop: La lista de verificacion completa de endurecimiento
• Respuesta ante brechas de datos: qué hacer si hackean tu tienda