Cuando una tienda online lleva unos años funcionando, el código deja de parecerse al que se diseñó. Se han instalado módulos para resolver urgencias, se han parcheado plantillas a mano para salir del paso en una campaña, se han añadido integraciones con el ERP, con el comparador de precios, con el marketplace y con tres herramientas de marketing distintas. Cada una de esas decisiones fue razonable en su momento. La suma, sin embargo, produce un sistema que nadie conoce del todo y que ha ido acumulando algo que en las reuniones se llama deuda técnica y que, desde fuera, se llama superficie de ataque.
El motivo por el que conviene plantearse una auditoría de seguridad ecommerce ahora y no el año que viene es sencillo: un ecommerce es un objetivo especialmente atractivo. Procesa pagos, almacena datos personales de miles de clientes, tiene picos de tráfico predecibles en los que cualquier caída cuesta dinero real y, con frecuencia, corre sobre una plataforma de código abierto cuyas vulnerabilidades son públicas en cuanto se anuncian. No hace falta que un atacante te elija: basta con que un escáner automático encuentre tu versión desactualizada.
Este artículo va de cómo se conectan tres cosas que muchas empresas tratan por separado: la optimización y limpieza del código, la auditoría de seguridad ecommerce y el pentesting. La tesis es simple: en un ecommerce no son proyectos distintos, son fases del mismo ciclo, y hacer solo uno de los tres da bastante menos resultado del que parece.
1. Por qué la deuda técnica es un problema de seguridad
La deuda técnica se suele presentar como un asunto de productividad: el código está enredado, cuesta más añadir funcionalidades, los desarrolladores se quejan. Todo eso es cierto y es insuficiente, porque deja fuera la parte que acaba en el titular.
Cada una de las formas habituales de deuda tiene una traducción directa en riesgo:
- Módulos y plugins sin actualizar. Es la vía de entrada número uno en tiendas construidas sobre plataformas populares. El CVE se publica, el exploit circula en horas y los escáneres automáticos barren internet buscando versiones vulnerables. No hace falta ser un objetivo, basta con ser alcanzable.
- Personalizaciones sobre el núcleo. Cuando se modifica el código base de la plataforma en lugar de extenderlo correctamente, actualizar deja de ser una tarea rutinaria y pasa a ser un proyecto. El resultado predecible es que se deja de actualizar.
- Código muerto y rutas heredadas. Endpoints de una integración que ya no se usa, un panel de importación de un proveedor antiguo, un script de migración olvidado en la raíz. Siguen siendo accesibles y suelen carecer de los controles que sí tiene el resto.
- Credenciales en el repositorio. Claves de la pasarela de pago, del ERP o del servicio de almacenamiento, commiteadas alguna vez y conservadas para siempre en el historial.
- Ausencia de entorno de pruebas y de tests. Sin un lugar donde comprobar los cambios, cada despliegue urgente se hace directamente en producción y cada corrección puede reabrir un fallo anterior.
- Registros insuficientes. Si no hay trazas útiles, una intrusión puede durar meses sin detectarse, y cuando se detecta no se puede determinar qué datos salieron. Esto último tiene consecuencias legales concretas: sin evidencia, hay que asumir el peor escenario en la notificación.
2. Qué revisa una auditoría de seguridad ecommerce
Una auditoría de seguridad ecommerce bien planteada no empieza lanzando herramientas. Empieza entendiendo el negocio, porque el riesgo no está repartido de forma homogénea: el formulario de contacto y el flujo de pago no merecen la misma atención.
2.1 Inventario y arquitectura
Qué componentes hay realmente en producción: versión de la plataforma, lista de módulos con su origen y su estado de mantenimiento, integraciones activas, servicios de terceros con acceso, entornos existentes y quién puede llegar a cada uno. Este paso solo ya suele destapar dos o tres cosas que nadie recordaba tener encendidas.
2.2 Revisión del código propio
Se concentra en los módulos a medida y en las personalizaciones, que es donde vive el código que ningún escáner conoce. Se buscan consultas construidas por concatenación, validaciones que solo existen en el navegador, comprobaciones de permisos ausentes en acciones sensibles, manejo inseguro de subidas de archivos y datos de sesión tratados a la ligera. La referencia práctica sigue siendo el OWASP Top 10 de vulnerabilidades web, que ordena bien por dónde mirar primero.
2.3 Los flujos críticos del negocio
Aquí es donde una auditoría de ecommerce se separa de una revisión genérica. Se prueba el flujo de pago completo buscando manipulación de importes, de portes y de descuentos entre el navegador y el servidor. Se prueba la gestión de cupones contra acumulación indebida y fuerza bruta. Se prueba el área de cliente con dos cuentas distintas para detectar acceso a pedidos ajenos. Se prueba el back office, que con frecuencia tiene una política de contraseñas más laxa que la del cliente final, y el proceso de devolución, un clásico para provocar inconsistencias.
2.4 Configuración e infraestructura
Cabeceras de seguridad, cifrado en tránsito bien configurado, permisos de ficheros, paneles administrativos accesibles desde internet, listados de directorios, copias de seguridad guardadas dentro del directorio público —más común de lo que parece— y separación real entre la tienda y el resto de sistemas.
2.5 Cumplimiento y datos
Si procesas tarjetas, PCI-DSS marca el terreno, aunque la mayoría de tiendas reducen mucho su alcance delegando el pago en la pasarela. En paralelo está el RGPD: qué datos personales se guardan, durante cuánto tiempo, quién accede y qué ocurre con las copias en entornos de prueba. Si la tienda vende también a organismos públicos, entra en juego el Esquema Nacional de Seguridad por vía contractual.
3. Dónde encaja el pentesting
La auditoría de seguridad ecommerce mira el sistema desde dentro, con acceso al código y a la configuración. El pentest lo mira desde fuera, como lo haría alguien con intención de entrar. Son complementarios y el orden importa: hacer el pentest antes de la auditoría suele producir un informe lleno de hallazgos evidentes que una revisión interna habría resuelto por una fracción del coste.
3.1 Modalidades y cuándo usar cada una
El caja negra parte de cero, sin información previa, y simula al atacante externo. Es el más realista y el menos eficiente: buena parte del tiempo contratado se va en reconocimiento. El caja gris proporciona credenciales de cliente y algo de contexto, y es el que mejor relación resultado-coste ofrece en un ecommerce, porque los fallos más graves suelen estar detrás del inicio de sesión. El caja blanca incluye acceso al código y a la arquitectura, y es el más exhaustivo cuando lo que se quiere es cobertura y no simulación. En la práctica, para una tienda consolidada, la recomendación habitual es caja gris con foco en checkout, área de cliente y back office. Desarrollamos el proceso completo en la guía sobre pentesting para tiendas online.
3.2 Lo que hace válido un pentest
Tres condiciones. Que exista un alcance escrito con lo que entra, lo que no, las ventanas horarias y los contactos de emergencia. Que el informe entregue reproducción paso a paso de cada hallazgo, no solo la captura de una herramienta: si tu equipo no puede reproducirlo, no podrá verificar que lo ha corregido. Y que incluya retest de los hallazgos críticos y altos dentro del mismo contrato, porque el valor no está en la lista de problemas sino en la confirmación de que dejaron de existir.
¿Cuándo fue la última vez que alguien miró el código de tu tienda?
Auditamos tiendas WooCommerce, PrestaShop, Magento y desarrollos a medida: inventario real, revisión del código propio, prueba de los flujos críticos y pentest con retest incluido. Los hallazgos llegan priorizados por riesgo y con el plan de corrección estimado.
4. Optimizar el código también es defenderlo
En una auditoría de seguridad ecommerce se ve claro que optimizar no es solo cosa de rendimiento ni asegurar solo cosa de seguridad, como si fueran departamentos distintos. En un ecommerce se solapan bastante más de lo que parece.
4.1 Menos código, menos superficie
Retirar los ocho módulos que se instalaron para probar y nunca se desinstalaron reduce a la vez el tiempo de carga y el número de componentes que hay que parchear. Es la mejora con mejor relación esfuerzo-resultado que existe, y casi siempre está pendiente.
4.2 La eficiencia es resistencia
Un endpoint que resuelve en 80 milisegundos aguanta un volumen de peticiones muy superior al mismo endpoint resolviendo en 2 segundos. Muchas caídas atribuidas a un ataque son en realidad consultas ineficientes que se agotan solas en cuanto alguien las llama en paralelo. Optimizar consultas, cachear con criterio y poner límites a la paginación es, funcionalmente, mitigación de denegación de servicio. Lo relacionado con el rendimiento medible lo tratamos en el artículo sobre Core Web Vitals e INP.
4.3 Código legible es código revisable
Una lógica de autorización distribuida en seis archivos y tres condiciones anidadas no se puede auditar con garantías, ni por una herramienta ni por una persona. Centralizarla y darle nombre no es estética: es lo que permite afirmar con seguridad quién puede hacer qué.
4.4 Actualizable es seguro
El objetivo final del trabajo de refactorización en un ecommerce es que actualizar la plataforma deje de dar miedo. Mientras actualizar sea un proyecto de tres semanas, no se hará; y mientras no se haga, las vulnerabilidades públicas se acumulan. Extender en lugar de modificar el núcleo, tener staging y automatizar el despliegue convierte la actualización en rutina. Es también el enfoque que aplicamos al hardening y mantenimiento de Magento 2.
5. Un ciclo anual de auditoría de seguridad ecommerce que un equipo pequeño puede sostener
Nada de lo anterior sirve como esfuerzo puntual. La propuesta práctica es un ciclo de cuatro tiempos que cabe en el trabajo normal de un equipo reducido.
Primer trimestre: auditoría técnica y de código. Inventario, análisis estático y de dependencias, revisión del código a medida y de los flujos críticos. Salida: lista priorizada y un puñado de correcciones rápidas aplicadas de inmediato.
Segundo trimestre: pentest de aplicación. Caja gris sobre checkout, cuenta de cliente y back office, con alcance escrito y reproducción detallada de cada hallazgo.
Tercer trimestre: remediación y verificación. Corregir lo crítico y lo alto, y hacer el retest. Es la fase que más se salta y la que determina si todo lo anterior sirvió de algo.
Cuarto trimestre: preparación de temporada alta. Pruebas de carga, revisión de límites y cabeceras, verificación de copias de seguridad con restauración real y plan de respuesta ante incidentes con teléfonos actualizados. Conviene cerrarlo antes de noviembre; el peor momento para descubrir que la restauración no funciona es durante la campaña.
Entre trimestres, lo automático sigue corriendo: escaneo diario de dependencias, alertas de disponibilidad y una ventana mensual de actualizaciones probadas primero en staging. Si además la tienda gestiona bien la conversión, el trabajo se refuerza: muchas de las mejoras que describimos en cómo optimizar el checkout de un ecommerce reducen fricción y superficie de ataque a la vez.
6. Cómo justificarlo ante dirección
Justificar una auditoría de seguridad ecommerce funciona mejor con números concretos que con advertencias generales. Tres cifras suelen bastar. La primera: cuánto factura la tienda por hora en un día normal y en un día de campaña, que es el coste directo de cada hora de caída. La segunda: cuántos registros de clientes hay en la base de datos, que es la escala de una eventual notificación por brecha de datos personales. La tercera: cuántos módulos en producción tienen vulnerabilidades conocidas hoy mismo, dato que se obtiene en una tarde y que suele terminar la discusión.
Con eso, el coste de un ciclo anual de auditoría y pentest se compara solo. Y a diferencia de un seguro, esta inversión deja algo tangible detrás: código más limpio, despliegues más rápidos y un equipo que sabe dónde está lo frágil.
7. Particularidades según la plataforma
Aunque el método de la auditoría de seguridad ecommerce es el mismo, cada plataforma concentra el riesgo en sitios distintos y conviene saberlo antes de repartir las horas de auditoría.
7.1 WooCommerce
El riesgo dominante es el ecosistema de plugins. Una tienda media acumula entre veinte y cuarenta extensiones, muchas de autores independientes y algunas ya sin mantenimiento. La revisión debe empezar por auditar esa lista: quién mantiene cada plugin, cuándo fue su última actualización y si existe alternativa mantenida. Se suma la superficie propia de WordPress —usuarios administradores de más, versiones expuestas, endpoints de la API REST accesibles sin autenticar—, que tratamos en detalle en la guía de seguridad de WordPress para empresas.
7.2 PrestaShop
Aquí el punto sensible suele ser el override y los módulos comprados en el marketplace. Los overrides mal usados rompen la ruta de actualización, y los módulos de terceros varían mucho en calidad de código: es habitual encontrar consultas sin preparar dentro de un módulo instalado hace años. También conviene revisar los permisos del back office, que tienden a acabar todos en el perfil de superadministrador por comodidad.
7.3 Magento y Adobe Commerce
Plataforma potente y compleja, con un historial conocido de ataques al proceso de pago mediante inyección de scripts en el checkout. La revisión prioriza la integridad de las plantillas del checkout, los parches de seguridad aplicados fuera del ciclo de versiones mayores y el control de acceso al panel de administración. Lo desarrollamos en el artículo sobre hardening y mantenimiento de Magento 2.
7.4 Plataformas SaaS y desarrollos a medida
En una plataforma alojada como servicio, buena parte de la infraestructura no es tuya y el foco se desplaza a lo que sí controlas: aplicaciones propias, integraciones, permisos de las claves de API y accesos de terceros. En un desarrollo a medida ocurre lo contrario: no hay comunidad publicando parches, así que todo el peso recae en tu ciclo de revisión interno y en las dependencias que hayas elegido.
8. Conclusión
En un ecommerce, seguridad y calidad de código son la misma conversación vista desde dos lados. La deuda técnica se paga tarde o temprano, y una de las formas de pagarla es un incidente. La alternativa razonable no es un gran proyecto de seguridad, sino un ciclo modesto y constante: saber qué tienes, revisarlo con herramientas, mirar con ojos humanos lo que las herramientas no entienden, probar con un pentest lo que el negocio no puede permitirse perder, corregir y verificar.
Si tu tienda lleva años sin una revisión de este tipo, el primer paso no es contratar el pentest más caro que encuentres. Es hacer inventario y una auditoría de seguridad ecommerce de diagnóstico. Casi siempre, el 80% del riesgo real está concentrado en un puñado de componentes que llevan demasiado tiempo sin que nadie los mire.
9. Preguntas frecuentes
¿Cada cuánto conviene hacer una auditoría de seguridad ecommerce?
Una auditoría técnica y de código al año como base, con pentest anual y verificación de dependencias en continuo. Si haces una migración de plataforma, cambias de pasarela de pago o abres una integración nueva con un tercero, conviene una revisión puntual adicional.
¿Sirve solo con un escáner automático de vulnerabilidades?
Como higiene mínima sí, y detecta versiones desactualizadas muy bien. Pero no encuentra fallos de lógica de negocio, manipulación de importes ni acceso a pedidos de otros clientes, que son precisamente los que más daño hacen en un ecommerce.
¿Puede un pentest tumbar mi tienda?
Un pentest bien planificado se acuerda con ventanas horarias, excluye pruebas destructivas salvo autorización expresa y mantiene un contacto directo para parar en cualquier momento. Las pruebas de carga o de denegación de servicio, si se incluyen, se hacen siempre en un entorno replicado.
¿Merece la pena refactorizar en lugar de rehacer la tienda?
Depende de cuánto del código actual sigue aportando valor. Si el problema son módulos acumulados y personalizaciones sobre el núcleo, refactorizar y ordenar suele ser mucho más barato. Si la plataforma está varias versiones mayores por detrás y sin ruta de actualización, la migración planificada acaba costando menos que el mantenimiento indefinido.
