A maioria dos periódicos em OJS é gerida por editores e bibliotecários, não por equipes de segurança. E tudo bem: quase nenhum dos incidentes em OJS é um ataque sofisticado. São o resultado de alguns padrões de fábrica que nunca foram alterados e de tarefas de manutenção que nunca foram agendadas.
Esta lista está ordenada por impacto. Se você tem só uma hora, faça os passos 1 a 6. Se tem uma tarde, faça os doze. Cada passo diz o que fazer, por que importa e onde encontrar no OJS.
Uma observação para periódicos brasileiros: os sistemas de indexação (SciELO, Redalyc, Latindex, DOAJ) e a avaliação da CAPES olham também para o site do periódico. Um site com páginas de spam ou sinalizado pelo Google como comprometido é um problema editorial, não apenas técnico.
1. Use uma versão do OJS com suporte
Cada versão do OJS corrige erros, e alguns desses erros são de segurança. Periódicos que continuam em 3.1 ou 3.2 carregam vulnerabilidades públicas há anos, e os scanners automáticos procuram exatamente essas versões.
O que fazer: atualize para uma versão atual 3.4.x ou 3.5.x e assine os comunicados do PKP para saber dos patches. Verifique sua versão em Administração → Informações do sistema.
2. Force HTTPS em todo o site
Sem HTTPS, cada login (editor, autor, avaliador) envia a senha em texto puro pela rede. É a correção mais barata da lista e uma das mais importantes.
O que fazer: instale um certificado (Let’s Encrypt é gratuito), configure base_url no config.inc.php com o endereço https:// e ative force_ssl = On na seção [security] para que o OJS redirecione qualquer requisição HTTP.
3. Mantenha o diretório de arquivos fora da raiz web
O OJS guarda arquivos de submissão, avaliação e composições finais no diretório definido por files_dir. Se esse diretório fica dentro da raiz pública do servidor web, um servidor mal configurado pode servir esses arquivos diretamente, e um atacante que consiga enviar um script pode executá-lo.
O que fazer: mova files_dir para um caminho que o servidor web não sirva (por exemplo /var/www/ojs-files em vez de /var/www/html/ojs/files) e confira que o config.inc.php não seja legível por todos os usuários do sistema.
4. Decida quem pode se cadastrar
O cadastro aberto é a origem de quase todo o spam no OJS. Bots criam centenas de contas, preenchem a biografia do perfil com links para cassinos ou farmácias, e seu periódico começa a ranquear por coisas que nunca escreveu. O Google percebe antes de você.
O que fazer: em Usuários e papéis → Opções de acesso ao site, revise se os usuários podem se cadastrar sozinhos e com quais papéis. Ative as opções de CAPTCHA no config.inc.php para o formulário de cadastro. Se o periódico tem uma comunidade de autores estável, considere cadastrar os autores manualmente.
5. Defina uma política de senhas de verdade
O OJS permite exigir um comprimento mínimo de senha com min_password_length no config.inc.php. O padrão é curto. Editores que gerenciam vários periódicos tendem a reutilizar senhas, que é exatamente o que os ataques de credential stuffing exploram.
O que fazer: aumente o mínimo para pelo menos 12 caracteres e peça à equipe editorial que use um gerenciador de senhas. Não compartilhe contas entre pessoas; cada ação no OJS deve poder ser atribuída a uma única pessoa.
6. Ative a autenticação de dois fatores para papéis com privilégios
Uma política de senhas reduz o risco. A autenticação de dois fatores elimina toda a categoria de incidentes do tipo “alguém conseguiu a senha” para as contas que importam: administradores do site, gerentes de periódico, editores.
O que fazer: o OJS não tem 2FA nativo, então é preciso um plugin. Nosso plugin de Autenticação de dois fatores adiciona códigos TOTP (Google Authenticator, Authy, Microsoft Authenticator, 1Password) com obrigatoriedade por papel, navegadores confiáveis e códigos de recuperação. Exija primeiro de administradores e editores, depois decida sobre autores e avaliadores. A configuração completa está no nosso guia de 2FA para OJS.
7. Audite quem ainda tem acesso
Periódicos mudam de mãos. Antigos editores, editores convidados de um número especial de três anos atrás, o estagiário que saiu: essas contas costumam manter papéis de Gerente ou Editor indefinidamente.
O que fazer: em Usuários e papéis → Usuários, filtre por papel e remova ou rebaixe quem não precisa mais de acesso. Mantenha o número de Administradores do site no mínimo, idealmente dois.
8. Limpe as contas spam e o spam em perfis
Se o periódico ficou com cadastro aberto por algum tempo, provavelmente já tem usuários spam. Os perfis deles estão indexados e diluem sua presença nos buscadores.
O que fazer: procure usuários com biografias contendo URLs, ordene por data de cadastro e procure rajadas de registros. O OJS oferece uma função de mesclagem de usuários para a limpeza; para volumes grandes, uma consulta na tabela de configurações de usuários é mais rápida. Depois, corrija as configurações de cadastro do passo 4, ou o problema volta.
9. Pratique higiene de plugins
Plugins rodam com os mesmos privilégios do OJS. Um plugin de origem desconhecida, ou abandonado há anos, é um risco.
O que fazer: instale plugins apenas da Galeria de plugins do PKP ou de desenvolvedores que você consiga identificar e contatar. Remova os que não usa mais. Prefira plugins que publiquem o código sob licença aberta para poder inspecioná-los; os nossos são GPL v3 exatamente por isso.
10. Faça backup de três coisas, e teste uma restauração
Uma instalação do OJS são três partes: o banco de dados, o diretório files_dir e o config.inc.php. Fazer backup só do banco é o erro mais comum; você mantém os metadados e perde todos os PDFs.
O que fazer: agende backups diários das três partes, guarde-os fora do servidor, mantenha várias gerações e, uma vez por trimestre, restaure um em uma máquina de teste para provar que o backup funciona.
11. Mantenha a plataforma sob o OJS atualizada
O OJS roda sobre PHP, um servidor web e um banco de dados. Cada um tem seu próprio ciclo de segurança. Rodar OJS 3.5 sobre uma versão de PHP que já não recebe correções anula o passo 1.
O que fazer: consulte os requisitos de PHP da sua versão do OJS, atualize os pacotes do servidor e desative a listagem de diretórios para que navegar em /plugins/ ou /cache/ não retorne nada útil.
12. Fique atento aos sinais de que algo já aconteceu
A maioria dos periódicos comprometidos é descoberta pelo Google, não pelos editores. Uma busca por site:seuperiodico.br que retorna páginas sobre criptomoedas ou medicamentos é o primeiro sintoma habitual.
O que fazer: verifique o periódico no Google Search Console e ative os alertas por e-mail; ele informa conteúdo hackeado e ações manuais. Uma vez por mês, faça você mesmo a busca site: e revise os cadastros de usuários mais recentes. Configure um monitor de disponibilidade para que uma queda seja notada em minutos, não quando um autor reclamar.
Mais uma coisa: confidencialidade dentro da avaliação por pares
Segurança não é só sobre intrusos. A avaliação cega depende de os arquivos não revelarem quem os escreveu, e um DOCX carrega o nome do autor, a instituição e o histórico de alterações nos metadados. Se o periódico faz avaliação duplo-cega, considere automatizar essa limpeza com o plugin Metadata Cleaner, que gera cópias anonimizadas dos arquivos de avaliação no momento do envio.
Por onde começar
Se hoje só dá para escolher três itens: atualize o OJS, force HTTPS e ative a autenticação de dois fatores em todas as contas que podem mudar uma decisão editorial. Esses três fecham as portas que realmente estão sendo testadas. O resto da lista as mantém fechadas.