La mayoría de las revistas en OJS las gestionan editores y bibliotecarios, no equipos de seguridad. Y está bien: casi ninguno de los incidentes en OJS es un ataque sofisticado. Son el resultado de unos cuantos valores por defecto que nunca se cambiaron y de tareas de mantenimiento que nunca se programaron.
Esta lista está ordenada por impacto. Si solo tienes una hora, haz los pasos 1 a 6. Si tienes una tarde, haz los doce. Cada paso indica qué hacer, por qué importa y dónde encontrarlo en OJS.
Un apunte para las revistas de América Latina: los sistemas de indexación (Redalyc, SciELO, Latindex Catálogo 2.0, DOAJ y, en Colombia, Publindex) evalúan también el sitio web de la revista. Un sitio con páginas de spam o marcado como comprometido por Google es un problema editorial, no solo técnico.
1. Usa una versión de OJS con soporte
Cada versión de OJS corrige errores, y algunos de esos errores son de seguridad. Las revistas que siguen en 3.1 o 3.2 arrastran vulnerabilidades públicas desde hace años, y los escáneres automáticos buscan exactamente esas versiones.
Qué hacer: actualiza a una versión actual de 3.4.x o 3.5.x y suscríbete a los anuncios de PKP para enterarte de los parches. Revisa tu versión en Administración → Información del sistema.
2. Fuerza HTTPS en todo el sitio
Sin HTTPS, cada inicio de sesión (editor, autor, revisor) envía la contraseña en texto plano por la red. Es lo más barato de arreglar de toda la lista y de lo más importante.
Qué hacer: instala un certificado (Let’s Encrypt es gratuito), configura base_url en config.inc.php con la dirección https:// y activa force_ssl = On en la sección [security] para que OJS redirija cualquier petición HTTP.
3. Mantén el directorio de archivos fuera de la raíz web
OJS guarda los archivos de envíos, revisiones y galeradas en el directorio definido por files_dir. Si ese directorio está dentro de la raíz pública del servidor web, un servidor mal configurado puede servir esos archivos directamente, y un atacante que consiga subir un script podría ejecutarlo.
Qué hacer: mueve files_dir a una ruta que el servidor web no sirva (por ejemplo /var/www/ojs-files en lugar de /var/www/html/ojs/files) y comprueba que config.inc.php no sea legible por todos los usuarios del sistema.
4. Decide quién puede registrarse
El registro abierto es el origen de casi todo el spam en OJS. Los bots crean cientos de cuentas, llenan la biografía del perfil con enlaces a casinos o farmacias, y tu revista empieza a posicionarse por cosas que nunca escribió. Google lo nota antes que tú.
Qué hacer: en Usuarios y roles → Opciones de acceso al sitio, revisa si los usuarios pueden registrarse por sí mismos y con qué roles. Activa las opciones de CAPTCHA en config.inc.php para el formulario de registro. Si tu revista tiene una comunidad de autores estable, considera registrar a los autores manualmente.
5. Define una política de contraseñas real
OJS permite exigir una longitud mínima de contraseña con min_password_length en config.inc.php. El valor por defecto es corto. Los editores que gestionan varias revistas tienden a reutilizar contraseñas, que es justo lo que aprovechan los ataques de relleno de credenciales.
Qué hacer: sube el mínimo a 12 caracteres como poco y pide al equipo editorial que use un gestor de contraseñas. No compartas cuentas entre personas; cada acción en OJS debería poder atribuirse a una sola persona.
6. Activa la autenticación de dos factores para los roles con privilegios
Una política de contraseñas reduce el riesgo. La autenticación de dos factores elimina toda la categoría de incidentes del tipo “alguien consiguió la contraseña” para las cuentas que importan: administradores del sitio, gestores de revista, editores.
Qué hacer: OJS no tiene 2FA integrado, así que hace falta un plugin. Nuestro plugin de Autenticación de dos factores añade códigos TOTP (Google Authenticator, Authy, Microsoft Authenticator, 1Password) con obligatoriedad por rol, navegadores de confianza y códigos de respaldo. Exígelo primero a administradores y editores, y después decide sobre autores y revisores. La configuración completa está en nuestra guía de 2FA para OJS.
7. Audita quién sigue teniendo acceso
Las revistas cambian de manos. Antiguos editores, editores invitados de un número especial de hace tres años, el auxiliar que se fue: sus cuentas suelen conservar roles de Gestor o Editor indefinidamente.
Qué hacer: en Usuarios y roles → Usuarios, filtra por rol y elimina o degrada a quien ya no necesite acceso. Mantén el número de Administradores del sitio al mínimo, idealmente dos.
8. Limpia las cuentas spam y el spam en perfiles
Si tu revista tuvo el registro abierto durante un tiempo, probablemente ya tiene usuarios spam. Sus perfiles están indexados y diluyen tu presencia en buscadores.
Qué hacer: busca usuarios con biografías que contengan URL, ordena por fecha de registro y busca ráfagas de altas. OJS ofrece una función de fusión de usuarios para la limpieza; para volúmenes grandes, una consulta en la tabla de configuración de usuarios es más rápida. Después corrige la configuración de registro del paso 4, o el problema vuelve.
9. Practica la higiene de plugins
Los plugins se ejecutan con los mismos privilegios que OJS. Un plugin de origen desconocido, o uno abandonado hace años, es un riesgo.
Qué hacer: instala plugins solo desde la Galería de plugins de PKP o de desarrolladores que puedas identificar y contactar. Elimina los que ya no uses. Prefiere plugins que publiquen su código con licencia abierta para poder inspeccionarlos; los nuestros son GPL v3 precisamente por eso.
10. Haz copia de tres cosas, y prueba una restauración
Una instalación de OJS son tres partes: la base de datos, el directorio files_dir y config.inc.php. Copiar solo la base de datos es el error más común; conservas los metadatos y pierdes todos los PDF.
Qué hacer: programa copias diarias de las tres partes, guárdalas fuera del servidor, conserva varias generaciones y, una vez por trimestre, restaura una en una máquina de prueba para demostrar que la copia funciona.
11. Mantén al día la plataforma bajo OJS
OJS corre sobre PHP, un servidor web y una base de datos. Cada uno tiene su propio ciclo de seguridad. Ejecutar OJS 3.5 sobre una versión de PHP que ya no recibe correcciones anula el paso 1.
Qué hacer: consulta los requisitos de PHP de tu versión de OJS, actualiza los paquetes del servidor y desactiva el listado de directorios para que navegar a /plugins/ o /cache/ no devuelva nada útil.
12. Vigila las señales de que algo ya pasó
La mayoría de las revistas comprometidas las descubre Google, no sus editores. Una búsqueda de site:turevista.edu.co que devuelve páginas sobre criptomonedas o medicamentos es el primer síntoma habitual.
Qué hacer: verifica la revista en Google Search Console y activa las alertas por correo; informa de contenido hackeado y de acciones manuales. Una vez al mes, haz tú mismo la búsqueda site: y revisa los registros de usuarios más recientes. Configura un monitor de disponibilidad para que una caída se detecte en minutos y no cuando un autor se queje.
Una cosa más: confidencialidad dentro de la revisión por pares
La seguridad no trata solo de intrusos. La revisión ciega depende de que los archivos no revelen quién los escribió, y un DOCX lleva el nombre del autor, su institución y el historial de cambios en sus metadatos. Si tu revista hace revisión doble ciego, considera automatizar esa limpieza con el plugin Metadata Cleaner, que genera copias anonimizadas de los archivos de revisión al subirlos.
Por dónde empezar
Si hoy solo puedes elegir tres puntos: actualiza OJS, fuerza HTTPS y activa la autenticación de dos factores en todas las cuentas que pueden cambiar una decisión editorial. Esos tres cierran las puertas que realmente se están probando. El resto de la lista las mantiene cerradas.