A default Joomla install on shared hosting is functional but exposed. The administrator login sits at a predictable URL, configuration.php often carries permissions wider than they should be, and the server sends no HTTP security headers unless you add them yourself. Bots scan continuously for /administrator/ and hammer it with credential-stuffing attempts, while automated scripts probe for writable directories they can drop a backdoor into. None of these weaknesses require a Joomla vulnerability to be exploited \u2014 they are configuration gaps that you, as an unprivileged hosting user, are fully able to close.

The work here is split across three fronts: filesystem permissions through File Manager, access control on the administrator path through .htaccess, and authentication plus HTTP hardening through the Joomla Global Configuration. You will not touch system services, PHP pool settings at the server level, or any file under /etc/. Everything happens inside your account under paths like /home/USER/public_html/, which is exactly where a shared-hosting account gives you authority.

Correcting file and directory permissions

LiteSpeed on CloudLinux runs your PHP under your own user via LSAPI, so there is no need to make files group- or world-writable for Joomla to function. Many migrated or hand-copied installs end up with loose modes such as 777 on directories or 666 on files, which lets any process write to them. The safe baseline is 755 for directories and 644 for files, with the single exception of configuration.php, which should be 444 (read-only) once the site is stable.

Open cPanel File Manager (or DirectAdmin's File Manager under System Info & Files) and navigate to /home/USER/public_html/. Select the top-level folders \u2014 components, modules, plugins, templates, libraries \u2014 right-click and choose Change Permissions, set them to 755, and apply recursively to folders only. For files, run a second pass setting 644. In cPanel's permission dialog the octal boxes correspond to Read/Write/Execute for User/Group/World; 755 means the three checkboxes read 7-5-5, and 644 reads 6-4-4.

configuration.php deserves special care because it contains your database credentials, secret key, and SMTP password in plain text. After your last edit, set it to 444:

File: /home/USER/public_html/configuration.php
Permissions: 0444 (r--r--r--)

Joomla will still read it on every request; it only needs write access when you save Global Configuration from the backend. If you need to change a setting later, temporarily set it to 644, save, then return it to 444. You can also deny direct web access to it and other sensitive files by adding this block near the top of /home/USER/public_html/.htaccess:

<FilesMatch "^(configuration\.php|\.htaccess|\.user\.ini)$">
  Require all denied
</FilesMatch>

Joomla's own internal includes bypass the web server for these reads, so blocking HTTP access breaks nothing. While you are in the account, confirm that no stray .php files sit inside images/ or tmp/ \u2014 those are the classic locations where an upload-based attack plants a shell. The following rule stops PHP execution in the images tree regardless of how a file arrived there:

<Directory "/home/USER/public_html/images">
  <FilesMatch "\.(php|phtml|php5|php7|phar)$">
    Require all denied
  </FilesMatch>
</Directory>

If your host does not permit <Directory> in a per-directory .htaccess, place a smaller .htaccess inside images/ containing only the <FilesMatch> block. Both approaches work on LiteSpeed, which reads Apache-style directives natively.

Protecting the administrator login path

The /administrator/ directory is the single most attacked URL on any Joomla site. You cannot rename it cleanly on all versions without breaking internal links, but you can gate it so that brute-force bots never reach the login form. The most reliable method on shared hosting is an IP allowlist combined with a secondary HTTP authentication layer, both set in a dedicated .htaccess placed at /home/USER/public_html/administrator/.htaccess.

If you administer from a static IP, restrict access to it directly:

# /home/USER/public_html/administrator/.htaccess
<RequireAny>
  Require ip 203.0.113.45
</RequireAny>

For admins on dynamic residential IPs, add an HTTP Basic layer instead so attackers hit a server-level password prompt before Joomla even loads. Create the password file outside the web root \u2014 use File Manager to place it at /home/USER/.htpasswd-admin \u2014 then reference it:

AuthType Basic
AuthName "Restricted Admin"
AuthUserFile /home/USER/.htpasswd-admin
Require valid-user

In cPanel you can generate this more comfortably through Directory Privacy: browse to the administrator folder, tick Password protect this directory, and add a user. cPanel writes the .htpasswd and the matching .htaccess for you, which is the cleaner route if you are uneasy editing files by hand. DirectAdmin offers the same under Password Protected Directories. The result is two independent credentials an attacker must pass, and most automated tools abandon the target at the first unexpected 401.

Reinforce this inside Joomla as well. Under Users \u2192 Manage \u2192 Options, confirm that new user registration is disabled unless you genuinely need public signups, and set the default new-user group to Registered rather than anything with backend rights. Enable Multi-Factor Authentication from Users \u2192 Multi-factor Authentication for every Super User account; Joomla 4 and 5 ship this natively with no plugin required.

HTTP headers and configuration hardening

Joomla 4 and later include a Global Configuration \u2192 Site \u2192 Behaviour / HTTP Headers plugin, but the most dependable place to enforce security headers on LiteSpeed is the root .htaccess, since it applies to every response including static assets and error pages. Add this block:

<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

Only add the HSTS line once you are certain every page loads over HTTPS, because it forces browsers to refuse plain HTTP for a year. Pair it with Joomla's own redirect: in Global Configuration \u2192 Server, set Force HTTPS to Entire Site. Then rename the bundled htaccess.txt in the web root to .htaccess if you have not already, and uncomment the RewriteEngine On and SEF rules so that the URL rewriting and the security blocks you added coexist.

Two further AdminCP settings reduce your exposure directly. Under Global Configuration \u2192 Server, set Error Reporting to None so stack traces and file paths never leak to visitors \u2014 check your account's error_log under /home/USER/public_html/error_log for debugging instead. Under Global Configuration \u2192 Site, keep Site Offline ready as an emergency switch if you detect compromise. Finally, use the .user.ini at the web root to cap upload abuse without server access:

; /home/USER/public_html/.user.ini
upload_max_filesize = 8M
post_max_size = 10M
allow_url_fopen = Off
display_errors = Off

Setting allow_url_fopen = Off blocks a common remote-file-inclusion vector, and disabling display_errors complements the Joomla error-reporting change. Changes in .user.ini take effect within a few minutes under LSAPI, or immediately after a cache-clear in the LiteSpeed Web Cache Manager if your plan exposes it.

With permissions tightened, the administrator path gated behind two credential layers, and security headers enforced at the edge, the typical automated attack surface against your Joomla site collapses. Keep the core and extensions updated from System \u2192 Update, and revisit these .htaccess rules after any major Joomla upgrade, since upgrades sometimes overwrite the bundled rewrite file and may drop your custom blocks.