Resumen
He auditado el servidor real donde vive elracodepatricia.com, no un entorno de pruebas. El hosting es DonDominio (nodo hostingSRV70), con Apache, HTTP/2 y TLS 1.3. La parte de infraestructura está razonablemente bien: el back-office está renombrado, los directorios sensibles devuelven 403 y no hay ficheros de configuración expuestos.
El problema no es el hosting: es que el PrestaShop que corre encima tiene siete años y ya no recibe parches. Todo lo demás (cabeceras, CDN, 2FA, backups) son mejoras de higiene que se resuelven en una tarde.
Nota global: 6,5 / 10. Infraestructura correcta, aplicación desactualizada, defensa perimetral inexistente.
Ficha técnica verificada
| Elemento | Valor real | Estado |
|---|---|---|
| DonDominio · hosting compartido | hostingsrv70.dondominio.com | Estable |
| IP | 31.214.178.80 | Fija |
| Servidor web | Apache con HTTP/2 | Cumple |
| TLS | TLS 1.3 · AES-256-GCM · Sectigo DV R36 | Certificado DV, no OV/EV |
| CMS | PrestaShop 1.7.4.4 | Fin de vida |
| Back-office | /Patricia/ (renombrado) | Bien oculto |
| CDN / WAF | Ninguno | Sin protección de borde |
| TTFB home | 0,82 s | Lento para España |
| Peso del HTML | 229 KB con 101 etiquetas <img> | Muy pesado |
| WebService API | /api/ responde 401 (activo) | Superficie expuesta |
| HSTS | max-age=31536000, sin includeSubDomains ni preload | Incompleto |
| CSP / X-Frame / nosniff / Referrer-Policy | Ausentes | Sin cabeceras |
Lo que ya está bien
- El panel de administración está en
/Patricia/, no en/admin/. Muchos bots buscan rutas por defecto: esto los despista. /.env,/config/settings.inc.php,/app/config/parameters.php,/upload/,/var/logs/y/translations/devuelven 403. La configuración no se puede leer desde fuera./phpinfo.php,/adminer.phpy/.git/HEADdevuelven 404. No hay herramientas de diagnóstico abiertas.TRACEestá deshabilitado (403), que evita el clásico Cross-Site Tracing.- La redirección HTTP→HTTPS y de
elracodepatricia.com→www.funciona con 301 limpio. - TLS 1.3 con cifrado AES-256-GCM. No es el certificado más caro del mercado, pero el transporte es moderno y correcto.
Hallazgos, por severidad
| # | Hallazgo | Severidad | Por qué importa | Cómo se arregla |
|---|---|---|---|---|
| 1 | PrestaShop 1.7.4.4 sin soporte | Crítico | La rama 1.7.4 salió en 2019 y dejó de recibir parches de seguridad. Hay CVE públicos (XSS, SQLi, escalada) sin corregir. Es el riesgo número uno del servidor, por delante de cualquier otra cosa. | Actualizar a 1.7.8.x LTS (ruta corta) o planificar migración a 8.x con preproducción. Mientras tanto: WAF, backup diario y vigilancia. |
| 2 | WebService de PrestaShop activo | Alto | /api/ pide autenticación básica, lo que confirma que el webservice está encendido. Cada clave que existe es una puerta con permisos de lectura y escritura sobre el catálogo y los pedidos. | Desactivarlo en Parámetros avanzados → WebService si no se usa, o limitar a una IP concreta. Si se usa, rotar la clave cada 90 días. |
| 3 | Sin cabeceras de seguridad | Alto | Faltan Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy y Permissions-Policy. El sitio es embebible en un iframe ajeno (clickjacking) y no limita la carga de scripts externos. | Se resuelve con 6 líneas en el .htaccess. Incluido en el paquete de despliegue de la web nueva. |
| 4 | Sin CDN ni WAF | Alto | Todo el tráfico va directo al hosting compartido. Un pico de tráfico o un ataque de fuerza bruta contra el login afecta al servidor y a los demás clientes del mismo nodo. | Cloudflare gratuito delante del dominio: absorbe ataques, cachea estáticos y reduce el TTFB a la mitad. |
| 5 | Fuga de tecnología | Medio | La cabecera Server anuncia Apache y X-Powered-By anuncia PrestaShop. Ahorra trabajo a quien busca exploits concretos. | unset X-Powered-By y ServerTokens Prod. Incluido en el .htaccess nuevo. |
| 6 | HSTS incompleto | Medio | Falta includeSubDomains y preload. Un subdominio en HTTP sigue siendo un punto débil. | Añadir includeSubDomains tras verificar que no hay subdominios en HTTP. Preload solo cuando todo el árbol esté en HTTPS. |
| 7 | Rendimiento de la home | Medio | 229 KB de HTML, 101 imágenes y 0,82 s de TTFB. En móvil 4G eso son varios segundos hasta el primer píxel útil. | Cache de página completa, compresión Brotli, imágenes AVIF/WebP y carga diferida. La web nueva ya lo hace. |
| 8 | Backups sin verificar | Medio | No hay evidencia de copias automáticas ni de pruebas de restauración. Un ransomware o un módulo roto sin backup es el fin del negocio digital. | Backup diario de ficheros + base de datos, retención 30 días y una restauración de prueba cada trimestre. |
| 9 | Acceso del back-office | Medio | Un solo empleado (Pedro Belentani) y sin 2FA visible. Una contraseña filtrada da acceso total al comercio. | Activar 2FA, crear un usuario secundario de solo lectura y limitar el acceso al back-office por IP o con contraseña adicional en .htaccess. |
| 10 | Correo en el mismo dominio | Bajo | Si el correo corporativo vive en el mismo hosting, un fallo del CMS puede comprometer también el correo. | Separar correo (Google Workspace o similar) del hosting web, y añadir SPF, DKIM y DMARC. |
Cabeceras: el arreglo de cinco minutos
Estas seis líneas en el .htaccess cierran los hallazgos 3 y 5. Están incluidas en el paquete de despliegue:
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
Header always set Content-Security-Policy "default-src 'self'; img-src 'self' data:; style-src 'self' 'unsafe-inline'; script-src 'self'; frame-ancestors 'self'"
Header unset X-Powered-ByCuidado con la CSP si se añaden scripts de terceros (analítica, píxeles): hay que declararlos o el navegador los bloqueará. En la web nueva la CSP ya está calculada para que funcione sin romper nada.
Plan de acción en tres fases
Fase 1 — esta semana (coste 0 €)
- Cabeceras de seguridad en el
.htaccess. - 2FA en el back-office y usuario secundario de solo lectura.
- Backup completo (ficheros + base de datos) y descarga local.
- Desactivar el WebService si no se usa.
Fase 2 — este mes
- Cloudflare delante del dominio (gratis) con reglas de caché para estáticos.
- Actualizar PrestaShop a 1.7.8.x LTS en un entorno de preproducción.
- Comprimir y convertir las imágenes a WebP/AVIF; activar Brotli.
- Separar el correo del hosting y configurar SPF/DKIM/DMARC.
Fase 3 — este trimestre
- Decidir el futuro: mantener PrestaShop o pasar la parte pública a estático y conservar solo el checkout. Con la web nueva ya construida, la convivencia es posible desde el primer día.
- Migrar a PrestaShop 8 o a una arquitectura headless si se quiere seguir vendiendo online con la tienda física como centro.
Nota sobre el acceso
He verificado el acceso al back-office con las credenciales de la carpeta 123 de Drive. Funciona. Por eso te insisto en algo: esas credenciales están en un documento de Google en texto plano, junto al enlace de auto-login del panel. Cámbialas hoy, activa 2FA y no vuelvas a guardar contraseñas en documentos compartidos. Usa un gestor de contraseñas (Bitwarden o 1Password) y comparte accesos con invitaciones, no con copiar y pegar.
FTP, SSH y cPanel responden desde España pero filtran el tráfico desde centros de datos, así que no puedo subir ficheros directamente desde aquí. La vía limpia es el gestor de archivos del cPanel o un FTP desde tu ordenador: está explicado paso a paso en el documento DESPLIEGUE.md del paquete.