How to Stop Spam User Registrations in OJS

Why OJS journals attract spam sign-ups

If your Users & Roles list is filling up with odd names, random email addresses and accounts that never submit anything, you have an OJS spam registration problem. It is one of the most common issues journal managers ask us about, and it is rarely personal. Bots find the form and fill it in, over and over.

OJS is an easy target for three reasons:

• The registration page is predictable. Every OJS journal has it at /index.php/yourjournal/user/register (or without index.php if clean URLs are on), so bots can find it automatically.
• Self-registration is on by default. Visitors can create accounts as readers and authors, and in many journals as reviewers too.
• There is no captcha out of the box. The default configuration ships with recaptcha = off.

Spam accounts do more harm than clutter. OJS sends a confirmation email to each new account, and messages to fake addresses bounce. This can damage your domain's sending reputation, so genuine review requests and decision letters start landing in junk folders. Fake reviewer accounts pollute reviewer searches. Some bots fill the biography or website fields with links, and some go on to send junk submissions.

Typical signs: registrations arriving in bursts, often overnight. Random-looking names, or the same text in the given and family name fields. Disposable or unrelated email domains. Links in the affiliation or biography. Accounts that never log in again.

How to stop OJS spam: the layered approach

No single setting stops every bot. The reliable approach is to stack several layers, so whatever gets past one is caught by the next. Here is what each layer does:

Step 1: Enable reCAPTCHA (or ALTCHA) to stop OJS spam bots

Get the keys. In Google's reCAPTCHA admin console, create a reCAPTCHA v2 "I'm not a robot" checkbox key, since that is the widget OJS's forms use. Add your journal's domain. Google may ask you to link the key to a Google Cloud project. You will receive a site key (public) and a secret key (private).

Add them to config.inc.php. Open config.inc.php in the OJS root folder, find the [captcha] section and change it as follows:

[captcha]
recaptcha = On
recaptcha_public_key = your-site-key
recaptcha_private_key = your-secret-key
captcha_on_register = On
captcha_on_login = On
recaptcha_enforce_hostname = On

In OJS 3.3 the section is the same except there is no captcha_on_login key, because 3.3 only protects the registration form. recaptcha_enforce_hostname makes OJS check that the solved captcha came from your own domain. Turn it on when the domain registered with Google matches your journal's domain.

Test it. Open the registration page in a private browser window and confirm the checkbox appears. If it does not, clear the template cache (Administration → Clear Template Cache). Then check whether your theme overrides the registration template. Some custom or third-party themes replace userRegister.tpl and drop the captcha block.

[captcha]
altcha = On
altcha_hmackey = 'replace-with-a-long-random-secret'
altcha_on_register = On
altcha_on_login = On
altcha_on_lost_password = On

Most journals should enable one captcha, not both. reCAPTCHA sends visitor data to Google, so mention it in your journal's privacy statement. That is one reason journals with strict data-protection rules prefer ALTCHA. PKP's administrator guide also lists the Form Honeypot plugin from the University of Pittsburgh. It adds a hidden field that people never see but bots fill in. Check that a release exists for your exact OJS version before you install it. Our list of essential OJS plugins explains how to install plugins safely.

Step 2: Require email validation for new accounts

Email validation stops bots that sign up with made-up addresses. With validation on, OJS disables every new account until the owner clicks the link in the confirmation email. The settings live in the [email] section:

[email]
require_validation = On
validation_timeout = 14

validation_timeout is the number of days the validation link stays valid. Existing accounts are not affected. Only new registrations have to be confirmed.

Automatic cleanup in OJS 3.4 and 3.5. These versions add user_validation_period in the [general] section (default 28). When require_validation is on, a daily scheduled task removes accounts that are older than this many days and have never been validated or logged in. Set it to 0 to switch the cleanup off. It only runs if your scheduled tasks work, so check them first.

Step 3: Restrict or close public registration

Decide which roles really need self-registration. Authors need accounts to submit, so most journals keep registration open for readers and authors and close it for reviewers. Editors then add reviewers deliberately.

1. Stop self-registration for a role

   Go to Users & Roles → Roles, open the menu next to the role (for example Reviewer), choose Edit, and under Role Options uncheck Allow user self-registration. Only Reader, Author and Reviewer roles can allow self-registration.

2. Close registration completely (if appropriate)

   Use Users & Roles → Site Access Options → User Registration. In OJS 3.3 and 3.4 you choose whether visitors can register or whether the journal manager enrols all accounts. In 3.5 the alternative is registration by invitation only. Alternatively, uncheck self-registration on every Reader, Author and Reviewer role, as PKP's administrator guide describes.

3. Tell authors how to get an account

   If registration is closed, add a line to About the Journal and the submission guidelines explaining who to contact for an account. Otherwise you will lose genuine submissions.

Closing registration suits invitation-only, institutional or conference journals. It is also a useful emergency brake during a heavy bot attack while you set up the other layers.

Step 4: Add server and CDN protection

Application settings only act once a request reaches OJS. Server-level protection filters junk traffic before PHP runs, which also keeps the site fast during an attack. In general terms:

• Web application firewall (WAF). Many hosts offer ModSecurity rule sets, and CDNs provide managed WAF rules and bot challenges. Turn on the protections your host or CDN offers.
• Rate limiting. Limit how many POST requests a single IP address can send to the registration, login and lost-password URLs within a minute. Real users register once, but bots submit hundreds of times.
• Block known bad bots. Block or challenge user agents and networks that only ever hit the registration form. Your access logs show these clearly as repeated POSTs to /user/register.
• Be careful with country blocking. Journals have international authors and reviewers. Blocking whole countries usually hurts more than it helps.

Not sure how to configure this on your server? Our OJS technical support service can set up captcha, validation and server-side protection together, and then clean up the accounts that already got in.

Find existing OJS spam users (read-only SQL)

Prevention stops new spam, but you still have the accounts that already exist. With a few dozen, you can review them by hand in Users & Roles. With thousands, use database queries to build a candidate list.

Query 1: accounts with no activity. This finds users who have no submission or editorial assignment, have never been asked to review, hold no role other than Reader, Author or Reviewer, and never came back after registering:

SELECT u.user_id, u.username, u.email, u.date_registered, u.date_last_login
FROM users u
WHERE u.date_registered >= '2025-01-01'          -- adjust the date range
  AND NOT EXISTS (SELECT 1 FROM stage_assignments sa WHERE sa.user_id = u.user_id)
  AND NOT EXISTS (SELECT 1 FROM review_assignments ra WHERE ra.reviewer_id = u.user_id)
  AND NOT EXISTS (
      SELECT 1
      FROM user_user_groups uug
      JOIN user_groups ug ON ug.user_group_id = uug.user_group_id
      WHERE uug.user_id = u.user_id
        AND ug.role_id NOT IN (65536, 4096, 1048576)  -- Author, Reviewer, Reader
  )
  AND (u.date_last_login IS NULL
       OR u.date_last_login < DATE_ADD(u.date_registered, INTERVAL 1 DAY))
ORDER BY u.date_registered DESC;

stage_assignments records submitters and editors on each submission, and review_assignments records reviewers, so genuine contributors drop out of the list. The role filter protects administrators, managers and editors. Some genuine readers will still appear, which is why you review the list before acting.

Query 2: which email domains dominate. A spike from one unfamiliar domain is a strong spam signal:

SELECT SUBSTRING_INDEX(email, '@', -1) AS domain, COUNT(*) AS accounts
FROM users
GROUP BY domain
ORDER BY accounts DESC
LIMIT 30;

Query 3: profiles stuffed with links.

SELECT u.user_id, u.username, u.email, u.url
FROM users u
WHERE (u.url IS NOT NULL AND u.url <> '')
   OR EXISTS (SELECT 1 FROM user_settings us
              WHERE us.user_id = u.user_id
                AND us.setting_name IN ('biography', 'affiliation')
                AND us.setting_value LIKE '%http%');

Export the results and spot-check a sample in Users & Roles. Then save the confirmed usernames in a plain text file, one per line (for example usernames.txt).

Remove spam users safely: merge, never DELETE

OJS stores user data in many tables: settings, roles, sessions, notifications, logs and more. In 3.4 and later, many of these are linked by foreign keys. A raw DELETE FROM users leaves broken records or fails halfway. PKP's own documentation is clear that accounts are removed by merging them into another account. The merged account is deleted, and anything attached to it moves to the target.

1. Back up

   Back up the database and the files directory, and confirm the backup is complete.

2. Create a dummy target account

   For example a user called deleted-spam, with only the Reader role and a strong password nobody uses.

3. Merge a few accounts in the browser

   Go to Users & Roles → Users and open the menu next to the spam user (a blue arrow in 3.3/3.4, three dots in 3.5). Choose Merge User, find deleted-spam, then click Merge into this user and confirm.

4. Merge many accounts from the command line

   For large lists, use the bundled CLI tool from the OJS root folder, as shown below.

cd /path/to/ojs

# Merge named accounts into the dummy account (the merged accounts are deleted)
php tools/mergeUsers.php deleted-spam spamUser1 spamUser2 spamUser3

# Users can also be given by ID
php tools/mergeUsers.php deleted-spam id=234 id=456

# Process a reviewed list in batches of 50
xargs -n 50 php tools/mergeUsers.php deleted-spam < usernames.txt

Run the tool as the same user the web server runs as, or fix ownership of cache/ afterwards. Try it on a staging copy first. If you are unsure about an account, disable it instead (Users & Roles → Users → Disable). Disabled accounts can't log in and can be re-enabled later.

Dealing with spam submissions

Bots and spammers sometimes get as far as submitting manuscripts: advertisements, gibberish or files with suspicious attachments. Handle them like this:

• Don't open suspicious attachments on your own computer. PKP's security guidance recommends extra caution with submissions that look odd.
• Decline the submission from the workflow. You can skip the notification email to the "author".
• Delete declined spam from the submissions list. The exact button location differs between 3.3, 3.4 and the redesigned 3.5 dashboard. For many at once, php tools/deleteSubmissions.php 123 124 125 permanently removes submissions by ID (3.3 to 3.5). OJS 3.3 also includes tools/deleteIncompleteSubmissions.php, which has a --dryrun option. Back up first, because both are irreversible.
• Merge the submitting account into your dummy account, as above.

Captcha plus email validation removes most spam submissions, because the bot never gets a working account.

When "OJS spam" means gambling or SEO spam pages

Sometimes people searching for "OJS spam" mean something more serious. Google shows pages on their journal's domain titled slot gacor, judi online, casino or pharmacy offers. Or a site:yourjournal.org search lists URLs nobody at the journal created.

That is not registration spam, and captcha or email validation will not fix it. It means someone has injected files, pages or database content into your site, often hidden so that only Googlebot sees it. Treat it as a security incident. Our step-by-step guide to cleaning a hacked OJS site covers finding the injected files, closing the entry point and recovering in Google Search. If the journal is live and indexed, contact our technical support team for urgent help.

OJS anti-spam checklist

• reCAPTCHA v2 (or ALTCHA in 3.5) is on, and the widget is visible on the registration page with your theme.
• require_validation = On, and validation emails reach Gmail and Outlook inboxes.
• In 3.4+, you have reviewed user_validation_period and confirmed that scheduled tasks run.
• Reviewer self-registration is off unless you really need it.
• Your host or CDN rate-limits POST requests to the register, login and password-reset URLs.
• Existing spam accounts have been identified with read-only queries, reviewed, and merged into one dummy account after a backup.
• OJS and plugins are up to date. Old releases are a common route to the far worse problem of injected spam pages.

Spam prevention is one part of keeping a journal healthy. Email delivery, scheduled tasks and updates matter just as much, and our guide to common OJS errors covers those. If you would rather have it done for you, OJS Academy has 10+ years of experience with OJS and can secure your registration forms, clean out existing spam users and set up monitoring through our OJS support service.

Frequently Asked Questions