Tu web carga, el formulario recibe consultas y el panel de administración responde. Son buenas señales de funcionamiento, pero para valorar la seguridad de tu web también necesitas revisar quién puede entrar, qué software utiliza y cómo detectarías un problema.
Esta guía está pensada para responsables de negocio que quieren conversar con su equipo técnico con preguntas concretas. Recorre estos siete puntos y pide una comprobación para cada uno. Te ayudarán a identificar tareas pendientes; una revisión inicial no certifica que una aplicación esté libre de vulnerabilidades.
Quién puede entrar y qué puede hacer
Empieza por las cuentas del gestor de contenidos, el alojamiento y los servicios conectados. Localiza usuarios de antiguos colaboradores y comprueba si personas que solo editan textos conservan permisos de administración. Cada cuenta debería tener un responsable y permisos adecuados a su trabajo.
La guía de autenticación de OWASP recoge medidas como la autenticación multifactor y la protección frente a intentos automatizados de acceso. Activa el segundo factor donde esté disponible y comprueba cómo se recupera una cuenta si se pierde el dispositivo habitual.
Si hay un área de clientes, pide además una prueba de separación de permisos con cuentas de prueba: un usuario debe acceder solo a los datos y operaciones que le corresponden. Ocultar un botón no sustituye la comprobación de permisos en el servidor.
Qué pedir: una relación de cuentas y permisos, confirmación de los accesos retirados y una prueba documentada de las restricciones del área privada, cuando exista.
Qué se actualiza y quién revisa los avisos
Una web puede seguir funcionando con componentes que ya no reciben mantenimiento. El inventario debe incluir el gestor de contenidos, extensiones, librerías y servicios que utiliza el proyecto. En un servicio gestionado, aclara qué actualiza el proveedor y qué queda a cargo de tu equipo.
OWASP recomienda un proceso para identificar y gestionar dependencias vulnerables. La utilidad de un aviso está en entender si afecta a tu aplicación, qué consecuencias tiene y quién se encargará de corregirlo.
Acuerda cómo se prueban los cambios y cómo se recupera el estado anterior si algo falla. Si una actualización queda pendiente por incompatibilidad, pide que se documente el motivo, la medida provisional y el responsable de resolverla.
Qué pedir: inventario de componentes, registro de actualizaciones y lista de avisos pendientes con su prioridad. «Está todo al día» necesita una comprobación que lo respalde.
Cómo se protege la conexión
Revisa que las páginas y formularios se sirvan mediante HTTPS sin avisos de certificado. Incluye el panel de administración y otros subdominios utilizados por el negocio. Comprueba también que alguien supervisa la renovación de los certificados.
La guía de seguridad del transporte de OWASP explica cómo proteger las comunicaciones. El cifrado protege los datos durante el tránsito; una vez recibidos, su protección depende también de la aplicación y de dónde se almacenen.
Qué pedir: una revisión de certificados, redirecciones y recursos cargados por las páginas. Una conexión cifrada sigue necesitando cuentas bien protegidas, permisos correctos y software mantenido.
Qué aceptan los formularios y las subidas de archivos
Un formulario conecta a cualquier visitante con una parte de tu sistema. Revisa qué información recibe, dónde se procesa y quién puede consultarla. Si permite adjuntar archivos, pregunta qué tipos y tamaños admite y dónde se guardan.
La guía de validación de entradas de OWASP indica que las comprobaciones deben realizarse en el servidor. Los mensajes del navegador ayudan al usuario, pero por sí solos no garantizan que el sistema rechace datos no permitidos.
Pide al equipo técnico que revise también los controles contra envíos abusivos y la forma en que se utilizan los datos recibidos. Validar un campo es una parte de la protección: las consultas a bases de datos y la presentación del contenido requieren sus propias medidas.
Qué pedir: pruebas controladas con datos ficticios que demuestren el rechazo de entradas y archivos no admitidos, sin enviar información real de clientes. Las pruebas que puedan afectar al servicio deben prepararse en un entorno adecuado.
Qué podrías recuperar con las copias
Para revisar este punto, plantea una situación concreta: alguien modifica contenido sin permiso o una actualización deja la web inutilizable. Pregunta qué copia se utilizaría, qué contiene y qué información reciente quedaría fuera al restaurarla.
Comprueba quién puede acceder a los respaldos y si una cuenta comprometida podría borrar también las copias. Pide que el equipo valore la separación de accesos y la protección frente a borrados según la plataforma que utilices.
Qué pedir: el resultado de una restauración en un entorno aislado, con las funciones y los datos comprobados. Recuperar una copia ayuda a volver a operar; también hay que investigar la causa del incidente y corregirla antes de reabrir el servicio.
El artículo sobre quién tiene las llaves de tu web incluye una ficha para documentar responsables, accesos y recuperación. Completa esa información con las condiciones de tu servicio de mantenimiento y cloud hosting.
Quién se entera cuando ocurre algo extraño
Una comprobación de disponibilidad puede avisar de una caída. Para investigar un acceso inesperado o un cambio de permisos hacen falta otros registros. Pregunta qué sucesos quedan anotados y cuáles generan un aviso al equipo responsable.
La guía de registros de OWASP aborda eventos como los fallos de autenticación y los errores de autorización. También explica que los registros deben protegerse y evitar información sensible innecesaria, como contraseñas o tokens de acceso.
Qué pedir: una prueba de alerta con un evento acordado y comprobar quién la recibe. Documenta el canal, la cobertura del servicio y qué ocurre cuando la persona habitual no está disponible. Guardar registros resulta útil cuando alguien puede consultarlos e interpretarlos.
Qué haríais ante una incidencia
Imagina que aparecen páginas que tu equipo no ha creado o que un usuario comunica un acceso inesperado. Debería estar claro a quién avisar, quién puede limitar el acceso afectado y quién toma decisiones sobre la continuidad del servicio.
Prepara con el equipo técnico una secuencia de actuación: registrar lo observado, conservar las evidencias disponibles, contener el problema, investigar y recuperar. La respuesta concreta dependerá del incidente. Evita que la primera decisión sea borrar todo sin valorar qué información necesita la investigación.
Qué pedir: un procedimiento breve con responsables y contactos, y un ejercicio de conversación sobre un caso ficticio. Si surgen dudas sobre quién decide o dónde están los registros, ya tienes tareas concretas que resolver.
Cómo convertir la revisión en un plan de trabajo
Para cada punto, anota la respuesta, la evidencia disponible, la acción pendiente y su responsable. Puedes usar estos estados: comprobado, pendiente de comprobar y requiere corrección. Evita marcar como seguro algo que todavía nadie ha revisado.
- Accesos: quién administra y qué permisos conserva cada cuenta.
- Actualizaciones: qué componentes se mantienen y qué avisos están pendientes.
- Conexión: certificados, renovación y páginas que utilizan cifrado.
- Entradas: validación de formularios, archivos y controles contra abuso.
- Recuperación: contenido de las copias y resultado de una restauración.
- Detección: eventos registrados, alertas y destinatarios.
- Respuesta: responsables, contactos y procedimiento de actuación.
Prioriza con el equipo técnico según los datos expuestos, los permisos afectados y la posibilidad de que el problema se aproveche. Una cuenta administrativa comprometida o una exposición de información requieren una atención distinta de una mejora documental. Si hay indicios de un incidente activo, aplica el procedimiento de respuesta.
Pide evidencias de la seguridad de tu web
Una revisión útil termina con comprobaciones y acciones asignadas. Saber qué está configurado, qué se ha probado y qué queda pendiente te permite decidir con más criterio y mantener esa revisión cuando cambien la web o el equipo.
En Dreamsite integramos medidas de seguridad en las aplicaciones y corregimos problemas técnicos dentro del alcance acordado. Cuéntanos qué web o aplicación necesitas revisar.
Fuentes y referencias
Preguntas frecuentes
¿Una web con HTTPS es segura?
HTTPS protege la comunicación entre el navegador y el servicio cuando está correctamente configurado. La seguridad de la web también depende de sus cuentas, permisos, código y datos almacenados. Comprueba el cifrado como una parte de la revisión y pide evidencias del resto de controles.¿Una web pequeña también necesita estas comprobaciones?
Sí, adaptadas a lo que utiliza. Una web informativa puede tener alojamiento, cuentas de publicación y un formulario externo que conviene revisar. Un portal con usuarios y datos privados necesita controles adicionales. Empieza por inventariar sus funciones y dependencias para definir un alcance proporcionado con el equipo técnico.¿Basta con instalar una herramienta de seguridad?
Una herramienta puede aportar controles o detectar determinados problemas, pero necesita configuración y seguimiento. Pregunta qué cubre, qué deja fuera y quién revisa sus avisos. También debes mantener el software, limitar permisos, comprobar las copias y preparar una respuesta ante incidentes.¿Este checklist sustituye a una auditoría de seguridad?
Sirve para organizar una primera conversación y localizar tareas pendientes. Una auditoría o prueba de intrusión tiene un alcance, una metodología y evidencias técnicas propias. Valora una revisión especializada según los datos que trata la aplicación, sus funciones, los cambios realizados y las necesidades del negocio.