Hosting y SSL de farmacia online: 88 de 104 con PHP sin soporte

Respuesta corta: candado, copias probadas, PHP con soporte y un plan de 72 horas

La seguridad de la tienda online de una farmacia se reduce a cuatro cosas que puedes comprobar tú mismo: un certificado válido que se renueve solo, copias que alguien haya probado a restaurar, una plataforma y una versión de PHP que sigan recibiendo parches, y saber qué hacer en 72 horas si se filtran datos de clientes (artículos 32 y 33 del RGPD).

Comprobado el 5-nov-2026. En MTRYX medimos desde fuera 432 tiendas del registro de venta online de la AEMPS, y el riesgo no está donde se suele mirar. El candado lo tienen 427 de las 432 (98,8 %). Lo que no se ve en el navegador es otra cosa: de las 104 tiendas que anuncian su versión de PHP, 88 (84,6 %) usan una rama que según el calendario oficial de php.net ya no recibe soporte, y 227 de 413 (55,0 %) no envían ninguna de las cinco cabeceras de seguridad básicas.

Sin soporte no quiere decir vulnerable: algunos alojamientos mantienen sus propios parches y no lo hemos comprobado. Quiere decir que esa tienda depende de que alguien lo vigile. Los calendarios de cada plataforma y de PHP los tienes en qué caduca y cuándo en el mantenimiento de una tienda; aquí no los repetimos.

Qué te exige la ley en seguridad (y qué no)

El Reglamento General de Protección de Datos (Reglamento UE 2016/679, texto del BOE leído el 5-nov-2026) no dice "pon un certificado SSL" ni "haz una copia diaria". Dice, en el artículo 32.1, que el responsable y el encargado del tratamiento «aplicarán medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo», y entre ellas lista el cifrado (letra a), «la capacidad de garantizar la confidencialidad, integridad, disponibilidad y resiliencia permanentes» de los sistemas (b), «la capacidad de restaurar la disponibilidad y el acceso a los datos personales de forma rápida en caso de incidente físico o técnico» (c) y «un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas» (d).

Lectura nuestra: la letra c) justifica tener copias y haberlas probado; la d) pide revisar las medidas con regularidad, no una vez al montar la tienda.

Los datos de un pedido de farmacia pueden ser datos de salud, y por eso el nivel de seguridad "adecuado al riesgo" se mide con ese listón y no con el de una tienda de camisetas. Los artículos 33 y 34 cubren el caso en que algo falla; los repasamos en el apartado de las 72 horas.

NIS2 en tres líneas (lectura nuestra)

NIS2 es la directiva europea de ciberseguridad. No suele alcanzar a una farmacia pequeña, y no por el sector: el Anexo I incluye al «prestador de asistencia sanitaria», y la Directiva 2011/24/UE mete la «dispensación» de medicamentos dentro de la «asistencia sanitaria». Lo que deja fuera a casi todas es el tamaño: se aplica a medianas empresas o mayores, y una pequeña ocupa a menos de 50 personas y no supera los 10 millones de euros (Recomendación 2003/361/CE). A 5-nov-2026 España no ha notificado la transposición (la Comisión Europea la remitió al Tribunal de Justicia de la UE el 8-jul-2026): una farmacia pequeña no entra por tamaño, una grande podría, y el RGPD sí te obliga ya. No sabemos cuántas farmacias del registro serían medianas: es una lectura de los textos, no un dictamen.

Certificado SSL de la tienda de una farmacia: qué mirar

El certificado pone el candado y cifra lo que viaja entre el cliente y tu tienda. INCIBE (guía de ciberseguridad en el comercio electrónico, 19-dic-2023) dice que para que el navegador lo reconozca «es necesario que lo proporcione una autoridad de certificación reconocida».

Lo que vimos el 5-nov-2026 al conectarnos a las 432 tiendas:

Qué sacar de esa tabla:

• El candado está resuelto en casi todas. Que 17 caduquen en un mes no es un riesgo por sí mismo si la renovación es automática (los certificados de Let's Encrypt se renuevan solos cuando está configurado). El problema es una renovación que depende de que alguien se acuerde: comprueba en tu panel que está activada.
• La redirección importa tanto como el certificado. Una tienda que responde en http sin redirigir deja al cliente que escribe la dirección a mano en la versión sin cifrar. Escribe la tuya empezando por http:// y comprueba que acaba en https://. En 4 de las 432 la portada se sirve en http sin redirigir, y otras 21 redirigen primero a otra dirección http (no sabemos si acaban en https).
• El contenido mixto es la excepción. Script, iframe u hoja de estilos cargados por http:// dentro de una página https. En las 380 portadas que respondieron con HTML, 5 (1,3 %) cargan algo así de forma activa y 11 más solo imágenes, audio o vídeo (2,9 %).

Hosting para una farmacia: qué preguntarle al proveedor

El hosting de una tienda de farmacia es el de cualquier comercio electrónico, con una diferencia: el proveedor guarda datos que pueden ser de salud. Preguntas para hacer y apuntar por escrito:

1. Qué tipo de alojamiento es. INCIBE distingue compartido, servidor privado virtual (VPS), dedicado y en la nube. Del compartido dice que «puede considerarse para pequeños negocios» y también que «puede suponer un riesgo en caso de que uno de los sitios web se vea vulnerado». No lo descarta: te pide saber en qué estás.

2. Dónde está el centro de datos y qué leyes se aplican. La misma guía pide mirar «la situación del centro de procesamiento de datos, o CPD, y las leyes que se aplican en el país donde está alojado».

3. Qué contrato de encargado hay. Cuando un proveedor guarda datos de tus clientes por tu cuenta, actúa como encargado. El artículo 28.1 del RGPD te pide elegir «únicamente un encargado que ofrezca garantías suficientes», y el 28.3 dice que el contrato debe obligarle a tomar las medidas del artículo 32 y, a tu elección, a devolverte o suprimir los datos al acabar el servicio, copias incluidas. Pídelo antes de contratar.

4. Cómo te avisaría de una brecha. El artículo 33.2 le obliga a notificarte «sin dilación indebida»; pregunta por qué canal.

5. Qué soporte tiene. INCIBE recomienda uno «eficiente y rápido (preferiblemente 24/7)».

6. De quién es el dominio y de quién la cuenta. Deben estar a nombre de la farmacia, no del proveedor: es lo que te deja marcharte sin perder la dirección. En MTRYX la tienda va en el dominio de la farmacia, y la guía para cambiar de proveedor sin perder el alta ni el SEO cuenta por qué importa.

7. Cuánto cuesta al año lo fijo. Suma hosting, dominio, certificado y mantenimiento: es lo que pagas aunque no vendas. En MTRYX no hay cuota mensual fija; es un 8-10 % solo de lo que vendes.

PHP: lo que sí se ve desde fuera

El PHP del alojamiento no es del todo invisible. 104 de las 413 tiendas que respondieron con una página (25,2 %) lo anuncian en las cabeceras de su servidor. Es solo una cuarta parte, pero con ella se cuenta esto, a 5-nov-2026 según php.net (dos años de soporte completo por rama y otros dos solo para fallos críticos de seguridad):

Son 88 sin soporte (84,6 % de las 104). Por plataforma, entre las que anuncian PHP, 76 de las 81 PrestaShop están en una rama sin soporte, y 6 de las 13 WooCommerce. Insistimos en el matiz, porque es el más fácil de leer mal: que una rama esté fuera del calendario de php.net no prueba que esa tienda sea vulnerable, porque algunos alojamientos mantienen ramas antiguas con parches propios. Te toca saberlo: pregunta a tu proveedor qué versión corre tu tienda y hasta cuándo la respalda.

Cabeceras y cookies: capas extra

Las cabeceras de seguridad son avisos que la tienda manda al navegador para que se proteja. Que falte una no es un fallo; son capas añadidas. Sobre las 413 tiendas que respondieron:

Sobre las 299 tiendas que envían una cookie de sesión, 111 (37,1 %) tienen alguna sin el atributo Secure y 72 (24,1 %) alguna sin HttpOnly. Qué pedir: que quien mantenga la tienda te diga si esas cabeceras están activas y, si no, por qué.

Copias de seguridad: qué decir y cómo probarlas

El RGPD pide, en el artículo 32.1.c, poder restaurar los datos «de forma rápida». La AEPD lo recoge en su listado de cumplimiento (guía de noviembre de 2019, con más de 12 meses). INCIBE añade tres ideas que se convierten en preguntas:

• Hacerlas. «Realizar copias de seguridad es importante para cualquier empresa y las tiendas de comercio electrónico no son una excepción.»
• Probarlas. «Otro punto importante es la realización de pruebas de restauración, ya que, si las copias realizadas son inaccesibles o se encuentran dañadas, un sistema de pruebas resolvería este problema.»
• Guardarlas aparte. «Es conveniente que el sistema de respaldo no comparta ningún tipo de infraestructura con el servidor principal.»

A quien guarda tus copias pregúntale, y pide la respuesta por escrito: cada cuánto se hacen y cuántas se conservan, dónde se guardan y si ese sitio es independiente del servidor de la tienda, cuánto se tarda en restaurar una (la respuesta que necesitas es un tiempo, no un "enseguida") y cuándo se probó por última vez.

Cómo se prueba una restauración sin complicarlo (criterio nuestro, no de INCIBE):

• Pide la restauración en un entorno de prueba, nunca encima de la tienda en vivo.
• Comprueba que la tienda arranca, que el último pedido está y que puedes entrar como cliente.
• Si tu tienda se sincroniza con tu programa de gestión, compara cinco referencias de la tienda restaurada con las del programa. En MTRYX nos conectamos a tu ERP, sea cual sea, con stock y precios en tiempo real, y cada pedido online queda en tu programa como una venta más; esa comparación de cinco referencias es la forma rápida de ver si lo restaurado está al día.
• Apunta la fecha y el resultado: el artículo 32.1.d habla de «verificación, evaluación y valoración regulares», y un papel con fecha es la prueba.

Datos de la tarjeta: redirección, campos incrustados y qué te toca

Aquí hay que ser prudente: lo que te exige el estándar de seguridad de las tarjetas (PCI DSS) depende de cómo esté integrada la pasarela de pago en tu tienda, y quien lo decide es tu banco. Es nuestra lectura de las dos fuentes que pudimos abrir: la FAQ 1588 del PCI Security Standards Council (febrero de 2025) y el manual de Redsys de integración por redirección (versión 2.1 del 20-sep-2016). No pudimos abrir el cuestionario SAQ A ni leímos la documentación de MONEI sobre PCI.

En nuestras palabras, la FAQ 1588 dice que los criterios del cuestionario SAQ A se aplican a un comercio cuya página incluye una página de pago incrustada de su proveedor (por ejemplo, un iframe) y no se aplican a un comercio cuya página redirige al cliente a la del proveedor. Y el comercio debe consultar a la entidad a la que presentará el cuestionario, normalmente su banco, si le toca y cuál.

Para ti, tres cosas. Averigua qué integración usa tu tienda. Pregunta a tu banco qué cuestionario te corresponde con esa integración. Y si alguien te dice que "la farmacia nunca toca datos de tarjeta", pídele que lo concrete: es cierto si el cobro va por redirección a la pasarela, y no se puede dar por hecho con cualquier otra integración.

Qué hacer en las primeras 72 horas de una brecha

Una brecha es, según la AEPD (página modificada el 14-sep-2026), «un incidente de seguridad que ocasione la destrucción, pérdida o alteración accidental o ilícita de los datos personales tratados por un responsable, o bien la comunicación o acceso no autorizados a los mismos». Combinamos los artículos 33 y 34 del RGPD con esa página; no leímos la guía de la AEPD sobre brechas (2018) ni abrimos Asesora Brecha.

1. Apunta la hora y avisa. El plazo empieza cuando tienes «constancia» de la brecha: «sin dilación indebida y, de ser posible, a más tardar 72 horas» (artículo 33.1). Tu proveedor de hosting, como encargado, debe avisarte a ti (33.2). Apunta la hora en que lo supiste y quién te lo dijo.

2. Valora el riesgo. No hace falta notificar si «es improbable que dicha violación de la seguridad constituya un riesgo para los derechos y las libertades de las personas físicas». La AEPD ofrece Asesora Brecha para ayudar a decidirlo. Aunque no notifiques, el artículo 33.5 te obliga a documentarla: hechos, efectos y medidas tomadas.

3. Notifica a la AEPD por su sede electrónica. Contenido mínimo, según el artículo 33.3: la naturaleza de la brecha (con categorías y número aproximado de afectados y de registros), un punto de contacto, las posibles consecuencias y las medidas adoptadas o propuestas. Si no puedes dar todo a la vez, se da por partes (33.4); si pasan las 72 horas, debe ir con los motivos de la demora (33.1).

4. Comunica a los afectados si el riesgo es alto. El artículo 34 lo exige ante un «alto riesgo» y pide hacerlo «en un lenguaje claro y sencillo». No hace falta si los datos afectados eran «ininteligibles» para quien no estuviera autorizado, «como el cifrado» (34.3.a); por eso el cifrado de la letra a) del artículo 32 no es un adorno.

La AEPD añade algo que quita miedo: notificar en tiempo y forma es evidencia de diligencia, y notificar no implica necesariamente que se abra un procedimiento; lo que está tipificado como infracción es no cumplir la obligación.

Lo que vemos en 432 tiendas: base y límites

Las cifras de tiendas de esta página salen del mismo trabajo, hecho en MTRYX y repetible: partimos de las 432 tiendas del registro de venta online de la AEMPS cuya portada abrió en nuestra lectura del 31-oct y 1-nov-2026, y el 5-nov-2026 (jueves) hicimos dos peticiones a cada una: la conexión con el certificado y la portada, y otra a la dirección http sin seguir la redirección, que es lo único que permite medir si redirige. No entramos en ninguna otra ruta. Publicamos solo cifras agregadas y no nombramos tiendas.

Del software de las portadas (recuento del 2-nov, sobre las mismas 432):

No son comparables con las de la página de mantenimiento (481 portadas): aquella usa otra base. La 3.5.0 de jQuery corrige un fallo de XSS, según el blog de jQuery de abril de 2020; una versión anterior es señal de que algo no se actualiza, no prueba de que la web sea vulnerable.

Los límites:

• Solo la portada, no el carrito ni el pago.
• Una sola IP y un jueves.
• Proxy y CDN. Cambian la cabecera Server y las de seguridad: 52 tiendas están detrás de Cloudflare, así que en ellas vemos lo que enseña ese intermediario.
• 11 tiendas respondieron 403, 500 o 503. Pueden esconder sus cabeceras tras un reto anti-robots y no cuentan en las cabeceras.
• Quedan fuera 373 filas del registro que no abrieron o no son tienda: no es el registro entero.
• Solo vemos lo que anuncian las cabeceras. El 74,8 % de las tiendas no anuncia su PHP, y de ellas no sabemos nada.

Diez comprobaciones para hoy

1. Certificado válido y renovación automática. Mira la fecha de caducidad y confirma en el panel que la renovación está activada.

2. Redirección. Escribe tu dirección con http:// y comprueba que acaba en https://.

3. Contenido mixto. Abre la portada y una ficha de producto con las herramientas del navegador abiertas y mira si hay avisos de recursos cargados por http.

4. Versión de PHP del alojamiento y hasta cuándo recibe parches. Compárala con php.net; el calendario de la plataforma y de PHP está en el mantenimiento de una tienda.

5. Contrato de encargado con tu proveedor. Por escrito, con lo que ocurre con los datos y las copias al terminar el servicio.

6. Copia reciente y última prueba de restauración, con fecha y con resultado.

7. Dónde se guardan las copias. Que no compartan infraestructura con el servidor principal.

8. Cabeceras de seguridad y cookies de sesión. Pregunta si HSTS y las demás están activas y si las cookies de sesión llevan Secure y HttpOnly.

9. Qué integración de pago tienes (redirección, campos incrustados o tarjeta por tu tienda) y qué cuestionario te pide tu banco.

10. Plan de brecha escrito: quién avisa a quién, dónde se apunta la hora de constancia y dónde está el formulario de la AEPD. Para el resto de requisitos de tu web, la auditoría de las 805 direcciones del registro lista las comprobaciones de avisos legales y devoluciones.

El panorama completo de abrir una tienda de farmacia, desde la ley hasta el envío, está en la guía para vender online desde una farmacia.