Cómo comprobar la seguridad de tu web sin hackear nada

Revisiones pasivas de seguridad para tiendas online: certificado TLS, HSTS, CSP, nosniff, cookies, contenido mixto, jQuery antiguo, security.txt y DMARC.

Equipo editorial de FixReports12 min de lectura

Puedes comprobar buena parte de la configuración de seguridad de una tienda online desde fuera, leyendo lo que el sitio ya envía a cualquier visitante: su certificado TLS, las redirecciones, las cabeceras de respuesta HTTP, las cookies, los scripts que carga y sus registros DNS públicos. Estas comprobaciones pasivas no envían tráfico de ataque ni requieren iniciar sesión, así que no suponen para la tienda más carga que una visita normal. Detectan fallos de configuración como un certificado a punto de caducar, la falta de HSTS, cookies inseguras, contenido mixto o una versión de jQuery con fallos conocidos. No son una prueba de penetración y no pueden demostrar que una tienda sea segura.

Puntos clave

  • Los certificados TLS de confianza pública emitidos desde el 15 de marzo de 2026 pueden tener una validez máxima de 200 días, que bajará a 100 días en marzo de 2027 y a 47 días en marzo de 2029 (CA/Browser Forum (se abre en una pestaña nueva)).
  • Los navegadores ignoran la cabecera HSTS cuando se envía por HTTP sin cifrar (MDN (se abre en una pestaña nueva)).
  • La directiva frame-ancestors de CSP no funciona en una etiqueta <meta>; tiene que enviarse como cabecera de respuesta (MDN (se abre en una pestaña nueva)).
  • Las versiones de jQuery anteriores a la 3.5.0 están afectadas por dos vulnerabilidades XSS, y la CISA añadió una de ellas, CVE-2020-11023, a su catálogo de vulnerabilidades explotadas conocidas (Known Exploited Vulnerabilities) el 23 de enero de 2025 (NVD (se abre en una pestaña nueva)).
  • Un archivo security.txt debe contener los campos Contact y Expires y estar en /.well-known/security.txt (RFC 9116 (se abre en una pestaña nueva)).

¿Qué se considera una comprobación de seguridad pasiva?

Una comprobación pasiva solo lee lo que el sitio o su DNS devuelven ante una petición normal.

Eso significa cargar páginas públicas, leer el certificado y las cabeceras de respuesta, enumerar las cookies y los scripts que establece una página y consultar los registros DNS públicos. Una comprobación pasiva no intenta adivinar contraseñas, no envía payloads de inyección, no sondea URL de administración y no escanea puertos. Todo lo que sigue se puede hacer con un navegador, curl, openssl y dig.

¿Cómo comprobar tu certificado TLS y su caducidad?

Lee directamente las fechas y los nombres del certificado, y asegúrate de que la renovación esté automatizada.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Comprueba que notAfter quede holgadamente en el futuro, que el certificado cubra tanto example.com como www.example.com si usas ambos (el visor de certificados del navegador muestra los nombres) y que el navegador no muestre ninguna advertencia. La vida útil de los certificados se está reduciendo según los Baseline Requirements del CA/Browser Forum (sección 6.3.2, versión 2.3.1 a octubre de 2026), tras la votación SC-081v3 (se abre en una pestaña nueva), aprobada el 11 de abril de 2025:

Certificado emitidoValidez máxima
Antes del 15 de marzo de 2026398 días
Del 15 de marzo de 2026 al 14 de marzo de 2027200 días
Del 15 de marzo de 2027 al 14 de marzo de 2029100 días
Desde el 15 de marzo de 202947 días

Con una vida útil tan corta, renovar a mano es arriesgado, así que confirma que tu proveedor de alojamiento o tu herramienta de certificados los renueva automáticamente. Confirma también que el HTTP sin cifrar redirige a HTTPS:

curl -sI http://example.com/ | grep -i -E "^HTTP|^location"

Lo que buscas es una respuesta 301 (o 308) con una cabecera location que empiece por https://.

¿Qué cabeceras de seguridad debería enviar una tienda online?

Un pequeño conjunto de cabeceras de respuesta bloquea ataques habituales en el navegador con un coste casi nulo.

CabeceraQué haceValor habitualFuente
Strict-Transport-SecurityIndica a los navegadores que usen solo HTTPS e impide que los usuarios ignoren los errores de certificadomax-age=31536000; includeSubDomainsMDN (se abre en una pestaña nueva)
Content-Security-Policy: frame-ancestorsControla qué sitios pueden incrustar tus páginas, lo que protege frente al clickjackingframe-ancestors 'self'MDN (se abre en una pestaña nueva)
X-Frame-OptionsControl de incrustación más antiguo; OWASP dice que frame-ancestors lo deja obsoleto en los navegadores compatiblesDENY o SAMEORIGINOWASP (se abre en una pestaña nueva)
X-Content-Type-OptionsImpide el MIME sniffing (que el navegador adivine el tipo de contenido) y bloquea los scripts y las hojas de estilo servidos con un tipo incorrectonosniffMDN (se abre en una pestaña nueva)
Referrer-PolicyLimita qué parte de tus URL se envía a otros sitiosstrict-origin-when-cross-originOWASP
X-XSS-ProtectionCabecera del filtro XSS del navegador; OWASP dice que puede crear vulnerabilidades XSS en sitios que, por lo demás, son segurosNo la configures, o usa 0OWASP

Comprueba qué envía tu tienda:

curl -sI https://example.com/

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: frame-ancestors 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Dos advertencias. includeSubDomains bloquea cualquier subdominio que solo funcione por HTTP, así que revisa antes los subdominios. La precarga de HSTS exige un max-age de al menos 31536000 e includeSubDomains, así que añade preload solo cuando todos los subdominios estén preparados para HTTPS. Vale la pena tener una CSP completa que restrinja los scripts, pero OWASP señala que es compleja de configurar y de mantener, y las tiendas con muchas apps deben probarla con cuidado.

¿Tienen tus cookies los atributos Secure, HttpOnly y SameSite?

Las cookies de sesión y de carrito deberían llevar los tres atributos, y puedes verlos en las cabeceras de respuesta Set-Cookie.

AtributoEfecto (según MDN (se abre en una pestaña nueva))Dónde importa
SecureSolo se envía por HTTPS; los sitios en HTTP sin cifrar no pueden establecerloTodas las cookies de una tienda con HTTPS
HttpOnlyJavaScript no puede leerla mediante document.cookie, lo que ayuda frente al XSSSesiones iniciadas y carritos
SameSite=Lax o StrictLimita cuándo se envía la cookie en peticiones entre sitiosSesiones; Strict es adecuado para las cookies de autenticación y de carrito
SameSite=NoneSe envía en peticiones entre sitios; debe combinarse con SecureSolo funciones incrustadas de terceros que lo necesiten

Si no se establece ningún atributo SameSite, los navegadores tratan la cookie como Lax. Las cookies que tus propios scripts necesitan leer no pueden ser HttpOnly, así que céntrate en las que identifican a un cliente con la sesión iniciada o a un administrador.

curl -sI https://example.com/ | grep -i "^set-cookie"

Las herramientas para desarrolladores del navegador muestran la misma información, incluidas las cookies que establecen los scripts después de cargar la página.

¿Cómo encontrar contenido mixto?

El contenido mixto es cualquier recurso cargado por HTTP en una página servida por HTTPS, y la consola del navegador lo muestra.

MDN (se abre en una pestaña nueva) lo divide en dos grupos. Las imágenes, el audio y el vídeo son «actualizables» (upgradable): los navegadores los solicitan automáticamente por HTTPS. Los scripts, las hojas de estilo, los iframes, las fuentes y las peticiones fetch() son «bloqueables» (blockable): los navegadores los bloquean, lo que rompe todo lo que dependía de ellos. Las peticiones actualizadas que apuntan directamente a una dirección IP también se bloquean.

Para encontrarlo, abre la consola en tus plantillas clave (inicio, colección, producto, carrito) y busca http:// en el código del tema, el contenido de las páginas y los ajustes de las apps. El centro de ayuda de Shopify dice que cualquier página de la tienda con un recurso que no se sirva por HTTPS se considera insegura (se abre en una pestaña nueva), y recomienda alojar los recursos en Shopify o servirlos por HTTPS. En WooCommerce, revisa el contenido de las entradas antiguas y las opciones del tema si el sitio funcionó alguna vez con http://.

¿Cómo detectar bibliotecas JavaScript obsoletas con CVE conocidas?

Enumera las bibliotecas que carga cada página, lee sus versiones y compáralas con la National Vulnerability Database (NVD).

Empieza por jQuery. En la consola del navegador, $.fn.jquery devuelve la versión cargada (API de jQuery (se abre en una pestaña nueva)). Versiones que debes señalar:

CVEVersiones afectadasProblemaPuntuación NVD (v3.1)
CVE-2020-11022 (se abre en una pestaña nueva)De la 1.12.0 a las anteriores a la 3.5.0Pasar HTML no fiable a métodos como .html() o .append() puede ejecutar código6,1, media
CVE-2020-11023 (se abre en una pestaña nueva)De la 1.0.3 a las anteriores a la 3.5.0Lo mismo, con HTML que contiene elementos <option>; en el catálogo KEV de la CISA desde el 23 de enero de 20256,1, media
CVE-2019-11358 (se abre en una pestaña nueva)Anteriores a la 3.4.0Contaminación de prototipos (prototype pollution) mediante jQuery.extend(true, ...)6,1, media

Los dos problemas de 2020 están corregidos en jQuery 3.5.0. Una versión vulnerable significa que el código defectuoso está presente; que se pueda explotar depende de cómo le pase los datos el sitio. WordPress incluye jQuery 3.5.1 desde la versión 5.6 (se abre en una pestaña nueva), así que un jQuery antiguo en una tienda WooCommerce apunta a un WordPress desactualizado o a un tema o plugin que carga su propia copia. En Shopify, revisa los archivos de tu tema y las apps que insertan scripts.

¿Qué es security.txt y lo necesita tu tienda?

Es un archivo de texto plano que indica a los investigadores de seguridad cómo comunicarte una vulnerabilidad.

La RFC 9116 (se abre en una pestaña nueva) (abril de 2022, una RFC informativa, por lo que seguirla es voluntario) establece que el archivo debe servirse por HTTPS en /.well-known/security.txt como text/plain. Contact y Expires son obligatorios, y la RFC recomienda que la fecha de Expires esté a menos de un año vista.

Contact: mailto:security@example.com
Expires: 2027-09-30T23:00:00.000Z
Preferred-Languages: en
Policy: https://example.com/security-policy

En WooCommerce puedes colocar el archivo en tu servidor. En una plataforma alojada, comprueba si puedes publicar un archivo en esa ruta; si no, un contacto de seguridad bien visible en tu página de contacto también ayuda.

¿Cómo protege DMARC tu tienda frente a la suplantación del email?

DMARC te permite pedir a los proveedores de correo que pongan en cuarentena o rechacen los mensajes que usan tu dominio en la dirección del remitente (From) sin superar SPF o DKIM alineados.

Un registro con p=none solo recopila informes; no detiene el correo suplantado. Los clientes esperan recibir de tu dominio las confirmaciones de pedido y los restablecimientos de contraseña, así que merece la pena bloquear un mensaje de phishing que muestra exactamente tu dominio. Comprueba tu política con dig +short TXT _dmarc.example.com y consulta la especificación en la RFC 9989 (se abre en una pestaña nueva). DMARC no cubre los dominios parecidos, solo el dominio que publica el registro.

¿Qué gestiona Shopify y qué controlas tú en WooCommerce?

Shopify gestiona los servidores de sus tiendas, mientras que una tienda WooCommerce autoalojada deja la configuración del servidor en tus manos y en las de tu proveedor de alojamiento.

ComprobaciónShopifyWooCommerce (autoalojado)
Certificado TLSGratis para todos los dominios añadidos a Shopify (se abre en una pestaña nueva); puede tardar hasta 48 horas en los dominios de tercerosTu proveedor de alojamiento o tu propia configuración
Redirección de HTTP a HTTPSPlataformaServidor web, CDN o ajustes del alojamiento
Cabeceras de seguridadLas envían los servidores de ShopifyServidor web, CDN o un plugin
Atributos de las cookiesLa plataforma establece las cookies propias de Shopify; las de las apps y del tema son responsabilidad tuyaNúcleo de WordPress, plugins y servidor
Contenido mixto y bibliotecas JSTu tema, tu contenido y tus appsTu tema, tu contenido y tus plugins
security.txt y DMARCTu dominio y tu DNSTu dominio y tu DNS

Cuando revisamos varias tiendas alojadas en Shopify en octubre de 2026, sus respuestas incluían HSTS con un max-age de unos 91 días, X-Content-Type-Options: nosniff y una CSP con upgrade-insecure-requests, mientras que frame-ancestors variaba de una tienda a otra. Shopify afirma que cuenta con la certificación PCI DSS de nivel 1 (se abre en una pestaña nueva). Tu tema y las apps que instales siguen siendo responsabilidad tuya.

En WooCommerce, la guía de refuerzo de la seguridad (se abre en una pestaña nueva) de WordPress aconseja mantener WordPress y los plugins actualizados, eliminar los plugins que no uses y preguntar a tu proveedor de alojamiento qué precauciones de seguridad toma.

¿Por qué esto no es una prueba de penetración?

Una prueba de penetración intenta ataques de forma activa; las comprobaciones pasivas solo observan.

La NIST SP 800-115 define las pruebas de penetración como pruebas de seguridad en las que los evaluadores imitan ataques reales para encontrar formas de eludir las funciones de seguridad de un sistema (glosario del NIST (se abre en una pestaña nueva)). Las comprobaciones pasivas no pueden ver fallos del lado del servidor en los plugins, contraseñas de administrador débiles o reutilizadas, la falta de autenticación en dos pasos, fallos de control de acceso ni código vulnerable que nunca aparece en el código fuente de la página. Úsalas como una referencia que puedes repetir en cualquier momento. Para una garantía mayor, encarga una prueba de penetración con un alcance por escrito, en sistemas que sean tuyos o que tengas autorización para probar.

Un análisis gratuito hace una primera revisión de tu tienda. El Informe de Seguridad Web cubre las comprobaciones pasivas de este artículo, desde TLS y las redirecciones hasta las cabeceras, las cookies, el contenido mixto, las bibliotecas obsoletas, security.txt y DMARC, con correcciones para cada hallazgo. Como cualquier revisión pasiva, no puede garantizar que una tienda sea segura.

Preguntas frecuentes

¿Las comprobaciones de seguridad pasivas ponen en riesgo mi tienda?

No más que una visita normal. Solicitan las mismas páginas públicas y los mismos registros DNS que pediría cualquier navegador o servidor de correo, y no intentan iniciar sesión ni enviar payloads de ataque.

¿Puedo añadir cabeceras de seguridad en Shopify?

Las cabeceras de respuesta de la tienda las envían los servidores de Shopify, así que contacta con el soporte de Shopify si falta alguna que necesites. Una etiqueta <meta> de CSP en tu tema puede añadir algunas directivas, pero MDN señala que frame-ancestors no se admite en <meta>.

¿Una versión antigua de jQuery significa que han hackeado mi tienda?

No. Significa que se carga código con vulnerabilidades conocidas, lo que aumenta el riesgo si el sitio pasa HTML no fiable a los métodos afectados. Actualízala o elimina el tema o el plugin que la carga.

¿Cuánto tiempo puede ser válido ahora un certificado TLS?

Los certificados de confianza pública emitidos a partir del 15 de marzo de 2026 pueden tener una validez máxima de 200 días. El límite baja a 100 días a partir del 15 de marzo de 2027 y a 47 días a partir del 15 de marzo de 2029.

¿Es obligatorio tener un archivo security.txt?

La RFC 9116 es una RFC informativa, así que, según el estándar, publicar el archivo es voluntario. Publicarlo cuesta poco y ofrece a los investigadores una forma clara de contactar contigo.

¿Un análisis pasivo sin problemas significa que mi tienda es segura?

No. Muestra que la configuración pública parece correcta. Las vulnerabilidades del lado del servidor, la seguridad de las cuentas y los fallos de lógica de negocio requieren otro tipo de pruebas.

Fuentes

Todas las guías