Common OJS Security Vulnerabilities to Watch For

Journal websites hold sensitive data: author contact information, unpublished manuscripts, reviewer identities, and editorial correspondence. A security breach doesn't just cause technical headaches—it damages trust, potentially violates privacy regulations, and can disrupt publication for months. Understanding common vulnerabilities helps journals protect their platforms and communities.

Why Journal Websites Are Targets #

Academic websites might seem unlikely targets, but attackers seek them for several reasons. University domains have high trust scores, making them valuable for hosting malicious content or sending spam. Journal databases contain email addresses useful for phishing campaigns. Outdated academic software often has known vulnerabilities that automated scanners easily identify.

Most attacks aren't personal—they're automated scans looking for any vulnerable target. Your journal doesn't need enemies; it just needs unpatched software to become a victim.

The Outdated OJS Problem #

Running outdated OJS versions represents the most common and serious vulnerability. The Public Knowledge Project regularly releases security patches addressing discovered vulnerabilities. Journals running old versions remain exposed to every vulnerability fixed since their last update.

OJS 2.x versions, in particular, no longer receive security updates. Journals still running OJS 2 are operating on software with known, unpatched vulnerabilities—a situation requiring urgent attention.

Even within OJS 3.x, significant security improvements separate older and newer releases. A journal running OJS 3.1 misses years of security work present in OJS 3.3 or 3.4.

The Upgrade Hesitation #

Many journals avoid upgrades fearing disruption, data loss, or the effort involved. This hesitation creates a dangerous false economy: the certain risk of running vulnerable software versus the manageable risk of a properly planned upgrade. Delaying upgrades doesn't reduce risk; it accumulates it.

Common Vulnerability Types #

SQL Injection #

SQL injection attacks manipulate database queries through malicious input. If user-supplied data isn't properly sanitised before database operations, attackers can extract data, modify records, or even take control of database servers.

OJS has addressed SQL injection vulnerabilities in various releases. Journals running older versions may remain vulnerable to attacks that newer versions prevent.

Cross-Site Scripting (XSS) #

XSS vulnerabilities allow attackers to inject malicious scripts into pages viewed by other users. These scripts can steal session cookies, redirect users to phishing sites, or modify page content. In a journal context, XSS could compromise editor accounts or distribute malware to visitors.

File Upload Vulnerabilities #

Journals accept file uploads—manuscript submissions, supplementary materials, images. Without proper validation, attackers might upload executable scripts disguised as documents. Once uploaded, these files could provide server access or spread malware to downloaders.

Authentication Weaknesses #

Weak password policies, lack of brute-force protection, and session management flaws can expose user accounts. Compromised editor or administrator accounts provide attackers significant control over journal operations and data.

Signs of Compromise #

Security breaches aren't always obvious. Watch for these warning signs:

Unexpected Content: Pages showing content you didn't create, strange links appearing in articles or sidebars, or spam content indexed by search engines under your domain.

Email Problems: Reports that emails from your domain are being blocked as spam, or evidence that your server is sending messages you didn't authorise.

User Complaints: Reports of redirects to strange sites, browser warnings when visiting your journal, or antivirus software flagging your pages.

Server Issues: Unexplained resource usage spikes, files you don't recognise in your web directories, or error logs showing unusual activity patterns.

Account Anomalies: User accounts you didn't create, password changes you didn't make, or evidence of access from unfamiliar locations.

Essential Security Practices #

Keep Software Updated #

This cannot be overstated: update OJS when new versions release, especially security updates. Subscribe to PKP's announcement channels to receive security notices. Treat security updates as urgent rather than optional.

Use HTTPS Everywhere #

Secure connections (HTTPS) protect data transmission between users and your server. Without HTTPS, login credentials and submitted manuscripts travel unencrypted, vulnerable to interception. Most browsers now warn users about sites lacking HTTPS—damaging trust before users even interact with your content.

SSL certificates are available freely through Let's Encrypt and other providers. There's no reason for journals to operate without HTTPS.

Implement Strong Password Policies #

Require strong passwords for all accounts, especially editors and administrators. Consider requiring periodic password changes and implementing two-factor authentication where possible. Prevent password reuse across accounts.

Regular Backups #

Comprehensive backups—database and files—provide recovery options if breaches occur. Test backup restoration periodically to ensure backups actually work. Store backups securely, separate from your web server.

Limit User Privileges #

Apply the principle of least privilege: users should have only the access necessary for their roles. Don't make everyone an administrator. Review user accounts periodically and remove inactive ones.

Monitor and Log #

Enable logging and review logs periodically for unusual patterns. Automated monitoring tools can alert you to anomalies requiring investigation. Knowing your normal traffic patterns helps you recognise abnormal ones.

The HTTPS Requirement #

Modern browsers increasingly enforce HTTPS. Chrome, Firefox, and Safari display warnings for non-HTTPS sites, particularly those with forms. Since journal sites collect user data through logins, submissions, and contact forms, lack of HTTPS creates visible warning messages that drive users away.

Beyond browser warnings, HTTPS is often required for ORCID integration, DOI resolution, and various API connections. Journals without HTTPS find themselves unable to implement standard scholarly infrastructure features.

When Breach Occurs #

If you discover or suspect a security breach:

Don't Panic—But Act Quickly: Rushed responses can cause additional damage. Take measured steps while treating the situation seriously.

Assess the Scope: What was accessed? What might have been modified? Understanding breach extent guides response.

Preserve Evidence: Before cleaning up, document what you find. Logs, modified files, and other evidence help understand what happened.

Contain the Damage: Take the site offline if necessary to prevent ongoing harm. Change compromised passwords. Revoke suspicious sessions.

Clean and Restore: Remove malicious content. Restore from clean backups if available. Update all software before bringing the site back online.

Notify Affected Parties: If user data was compromised, notification may be legally required and is ethically appropriate. Transparency maintains trust better than concealment.

Security as Ongoing Commitment #

Security isn't a one-time implementation but an ongoing practice. Threats evolve; defences must evolve with them. Regular updates, periodic audits, and continuous monitoring form the foundation of sustained security.

Journals that invest in security protect their authors, reviewers, editors, and readers. This protection reflects the same care for community that quality peer review and ethical publication demonstrate.