Most OJS journals are run by editors and librarians, not security teams. That is fine: the majority of OJS incidents are not sophisticated attacks. They are the result of a handful of defaults that were never changed and a few housekeeping tasks that were never scheduled.
This checklist is ordered by impact. If you only have an hour, do steps 1 to 6. If you have an afternoon, do all twelve. Each step says what to do, why it matters, and where in OJS to find it.
1. Run a supported OJS release
Every OJS release fixes bugs, and some of those bugs are security issues. Journals still running 3.1 or 3.2 carry vulnerabilities that have been public for years, and automated scanners look for exactly those versions.
What to do: upgrade to a current 3.4.x or 3.5.x release and subscribe to the PKP announcements so you hear about patches when they ship. Check your version under Administration → System Information.
2. Force HTTPS everywhere
Without HTTPS, every login (editor, author, reviewer) sends a password in clear text over the network. This is the cheapest thing on the list to fix and one of the most important.
What to do: install a certificate (Let’s Encrypt is free), set base_url in config.inc.php to the https:// address, and enable force_ssl = On in the [security] section so OJS redirects any plain HTTP request.
3. Keep the files directory outside the web root
OJS stores submission files, review files and galleys in the directory set by files_dir. If that directory sits inside the public web root, a misconfigured server can serve those files directly, and an attacker who manages to upload a script can execute it.
What to do: move files_dir to a path that the web server does not serve (for example /var/www/ojs-files rather than /var/www/html/ojs/files), and make sure config.inc.php itself is not world-readable.
4. Decide who is allowed to register
Open registration is how most OJS spam starts. Bots create hundreds of accounts, fill the profile biography with links to casinos or pharmacies, and your journal starts ranking for things you never wrote. Google notices before you do.
What to do: in Users & Roles → Site Access Options, review whether users may register themselves and for which roles. Enable the CAPTCHA options in config.inc.php for the registration form. For journals with a stable author community, consider registering authors manually.
5. Set a real password policy
OJS lets you require a minimum password length through min_password_length in config.inc.php. The default is short. Editors who manage several journals tend to reuse passwords, which is exactly what credential-stuffing attacks rely on.
What to do: raise the minimum to at least 12 characters, and ask editorial staff to use a password manager. Do not share accounts between people; every action in OJS should be traceable to one person.
6. Turn on two-factor authentication for privileged roles
A password policy reduces risk. Two-factor authentication removes the whole category of “someone got the password” incidents for the accounts that matter: site administrators, journal managers, editors.
What to do: OJS has no built-in 2FA, so you need a plugin. Our Two-Factor Authentication plugin adds TOTP codes (Google Authenticator, Authy, Microsoft Authenticator, 1Password) with per-role enforcement, trusted browsers and backup codes. Require it for admins and editors first, then decide about authors and reviewers. The full setup is covered in our 2FA guide for OJS.
7. Audit who still has access
Journals change hands. Former editors, guest editors from a special issue three years ago, the student assistant who left: their accounts often keep Journal Manager or Editor roles indefinitely.
What to do: in Users & Roles → Users, filter by role and remove or downgrade anyone who no longer needs access. Keep the number of Site Administrators to the minimum, ideally two.
8. Clean up spam accounts and profile spam
If your journal has had open registration for a while, you probably already have spam users. Their profiles are indexed and they dilute your search presence.
What to do: search users for biographies containing URLs, sort by registration date and look for bursts of registrations. OJS offers a merge-users function for cleaning up; for large volumes, a database query on the user settings table is faster. Afterwards, fix the registration settings from step 4 or the problem returns.
9. Practise plugin hygiene
Plugins run with the same privileges as OJS itself. A plugin from an unknown source, or one that was abandoned years ago, is a liability.
What to do: install plugins only from the PKP Plugin Gallery or from developers you can identify and contact. Remove plugins you no longer use. Prefer plugins that publish their source under an open licence so you can inspect them; ours are GPL v3 for exactly that reason.
10. Back up three things, and test a restore
An OJS installation is three parts: the database, the files_dir directory and config.inc.php. Backing up only the database is the most common mistake; you keep the metadata and lose every PDF.
What to do: schedule daily backups of all three, store them off the server, keep several generations, and once a quarter restore one to a test machine to prove the backup works.
11. Keep the platform under OJS current
OJS runs on PHP, a web server and a database. Each has its own security lifecycle. Running OJS 3.5 on a PHP version that stopped receiving security fixes defeats the purpose of step 1.
What to do: check the PHP requirements for your OJS release, upgrade the server packages, and disable directory listing so that browsing /plugins/ or /cache/ returns nothing useful.
12. Watch for signs that something already happened
Most compromised journals are found by Google, not by their editors. A search for site:yourjournal.org that returns pages about cryptocurrency or prescription drugs is the usual first symptom.
What to do: verify the journal in Google Search Console and enable email alerts; it reports hacked content and manual actions. Once a month, run the site: search yourself and review the newest user registrations. Set up uptime monitoring so an outage is noticed within minutes, not when an author complains.
One more thing: confidentiality inside peer review
Security is not only about intruders. Blind peer review depends on files not revealing who wrote them, and a DOCX carries the author’s name, institution and tracked-changes history in its metadata. If your journal runs double-blind review, consider automating that cleanup with the Metadata Cleaner plugin, which produces anonymised copies of review files as they are uploaded.
Where to start
If you have to pick three items today: update OJS, force HTTPS, and enable two-factor authentication for every account that can change an editorial decision. Those three close the doors that are actually being tried. The rest of the list keeps them closed.