Disable The Joomla API (Web Services)

What this check and mySites.guru tool looks at on your site

Two rows cover the Joomla API, which Joomla calls Web Services. The first, Joomla API (Web Services) Enabled, is a read-only check. The second, Disable The Joomla 4+ API (Web Services) Layer, is the one-click toggle that switches it off. Both apply to Joomla 4.0.0 and later, because Joomla 3 has no API layer.

On every snapshot the connector counts the API plugins that are enabled in your site’s #__extensions table, across both of the folders the API depends on. The webservices folder holds one plugin per area of the site (content, users, config, media and so on), and a route only exists while its plugin is on. The api-authentication folder holds the plugins that decide who may log in to the API, Token authentication (on by default) and Basic authentication (off by default).

The count leaves out one plugin on purpose, the Joomla Update web service, because that is how Joomla’s automated core updates reach your site. It is reported separately. A count of zero means the API is off.

The check row reads OK at zero and Enabled with the number of plugins when any are on. Two findings outrank a plain “on” and read as danger:

• CVE, when the API is on and the site runs Joomla 4.0.0 to 4.2.7, the versions exposed to CVE-2023-23752.
• Basic, when the Basic authentication plugin is enabled, because that lets the API accept a Joomla username and password.

A site that has not sent a snapshot since the check was added reads No Data, never “off”. The toggle row reads OK when the API is off and On when it is not.

The Investigate page on the check row goes further. It lists every plugin in both folders with a flag saying whether it is core or third-party, whether Joomla Update is installed and enabled, whether automated updates are switched off, and the users who hold an enabled API token, by id, username and name. It never reads or sends the token itself.

An API most sites never call, open on every one

Joomla switched the API on by default from 4.0 onwards, so every Joomla 4, 5 and 6 site exposes it until someone turns it off. Most sites never use it. Brochure sites, club sites and small shops have nothing outside the site talking to /api/, yet the endpoint still answers.

While the API is on, a request to /api/index.php/v1/... without valid credentials gets a 401. That is a login prompt, and it means everything behind it is only as strong as the authentication in front of it. With the API off, the same request gets a 404, because the route does not exist.

The history shows why that difference matters. CVE-2023-23752 let anyone read a site’s configuration.php, database password included, through the API on Joomla 4.0.0 to 4.2.7, with no login at all. Updating to 4.2.8 or later fixes that particular hole. Switching the API off removes the whole surface, so the next flaw in an endpoint you never use has nothing to reach.

Basic authentication is the other finding the check treats as danger. With it enabled, the API accepts a Joomla username and password directly, and it does so with no two-factor step. A site that enforces MFA on its administrator login can still be reached with a password alone through /api/. Token authentication, the default, does not have that weakness, which is why the check flags Basic and not Token.

The list of token holders on the Investigate page answers the question the plugin count cannot: who could actually use the API today. An integration account set up for a project that ended years ago still has a working token until someone revokes it.

Off, unless something outside the site needs it

If nothing on your site talks to the Joomla API, it should be switched off. If something does, keep the API on, keep Basic authentication off, and review the token holders on the Investigate page so only the accounts that need a token have one.

Automated core updates need a decision of their own. Joomla 5.4 and later deliver them by calling back into your site through the Joomla Update web service, which is why the toggle leaves that one plugin running. If you want the API completely off, flip Disable Joomla 5.4+ Automatic Core Upgrades as well. Doing both ends Joomla’s automated core updates, and you then update Joomla through mySites.guru or by hand. Make that choice deliberately, because when automated updates stop, the only sign Joomla core gives is the administrator health icon turning unhealthy after four days.

How to fix it

To do it by hand on one site:

1. Log in to https://yoursite.com/administrator.
2. Go to System, then Plugins under Manage.
3. Open Filter Options and set the type filter to webservices.
4. Tick every plugin except Web Services - Joomlaupdate and click Disable.
5. Change the type filter to api-authentication and disable every plugin listed there.
6. Request https://yoursite.com/api/index.php/v1/content/articles from outside. A disabled API answers 404.

Keep Web Services - Joomlaupdate enabled unless you have also switched off automated updates. Disable these plugins rather than uninstalling them: none of them is protected, so Joomla’s own Plugins manager can switch them off, and they are all locked, which only blocks uninstall.

Third-party extensions can ship their own webservices and api-authentication plugins, so check the filtered lists for anything that is not core. Repeat the check after major Joomla updates, since a core update can install a new Web Services plugin enabled. For a second layer, block /api/ at the server with an .htaccess, nginx or Cloudflare rule, which a Joomla update leaves alone. If you keep automated updates, exempt the /v1/joomlaupdate/ path from that rule.

What mySites.guru does about it

The check runs on every snapshot of every connected Joomla 4, 5 and 6 site, so a site that has the API on, Basic authentication enabled, or a vulnerable 4.x version with the API exposed shows up without anyone logging in to look.

The toggle switches the API off in one click. It disables every plugin in both the webservices and api-authentication folders, core and third-party alike, except the Joomla Update web service, so automated core updates keep working. It then re-counts and reports an error if anything is still on, and clears the Joomla caches so the backend matches what the database now says. Nothing is uninstalled and no content is touched.

Flipping it back restores Joomla’s defaults. The core web services and Token authentication come back on. Basic authentication and third-party API plugins stay off, so re-enabling the API never opens a login the site did not have on a fresh install.

To change many sites at once, use the same toggle from Tools across all your sites. Each site gets the same change and reports its own result, which on a portfolio of Joomla sites is the difference between an afternoon in Plugins managers and a single click. For sites where the API should be off completely, pair it with Disable Joomla 5.4+ Automatic Core Upgrades and keep patching through mySites.guru.