A default phpBB installation is functional and reasonably safe, but the assumptions it makes about your environment rarely match a shared hosting account. The forum root sits inside public_html, which means every file, including config.php and the installer, is reachable over HTTP unless you take deliberate steps. Bots crawl new domains within hours looking for exposed admin control panels, writable directories, and open registration forms they can flood with spam accounts. On a managed cloud shared server running LiteSpeed and CloudLinux, you cannot touch the web server config or PHP master settings, so all hardening happens at the account level: file permissions through File Manager, request filtering through .htaccess, PHP behaviour through .user.ini, and the rest inside the phpBB Administration Control Panel (ACP).

The good news is that phpBB gives you enough control to close every common weakness without root access. The work breaks down into four areas: protecting sensitive files and leftover install artifacts, restricting access to the ACP, tightening registration and posting to stop spam, and sending the HTTP headers modern browsers use to blunt cross-site attacks. Each one addresses a distinct attack surface, and together they turn a stock board into something that resists the automated traffic every public forum attracts.

Locking down config.php, the installer, and writable folders

The single most sensitive file in a phpBB install is config.php at the forum root. It contains your database name, database user, and database password in plain text. On a shared server the correct permission is 644 (owner read/write, group and world read) — phpBB only needs to read it, never write to it after installation. Never set it to 666 or 777; those values let any other process on the account, or a compromised script, rewrite your database credentials. In cPanel open Jupiter > Files > File Manager, navigate to the folder holding your board (for example public_html/forum), right-click config.php, choose Change Permissions, and confirm the numeric value reads 0644. DirectAdmin Evolution exposes the same control under File Manager with the permissions column on the right.

After you finish installing or upgrading, phpBB expects you to delete or rename the installer. Leaving install/ in place lets an attacker re-run setup routines and, in some versions, read configuration data. Remove the entire install/ directory through File Manager once the board is live. The folders phpBB genuinely needs to write to are cache/, store/, files/, and images/avatars/upload/; these should be 755 for directories and 644 for files. Avoid the temptation to blanket-chmod the tree to 777 when a feature misbehaves — the real fix is almost always the PHP handler user matching the account owner, which is already the case under CloudLinux.

You can add a second layer for config.php by denying direct web requests to it. Drop this into the .htaccess file in your board root:

<Files config.php>
    Require all denied
</Files>

<FilesMatch "\.(sql|log|bak|inc)$">
    Require all denied
</FilesMatch>

phpBB includes .htaccess protection inside store/, cache/, and files/ by default, but verify those files still exist after a migration — some backup tools skip dotfiles and silently strip the protection that keeps session data and cached templates out of public view.

Protecting the ACP with a second authentication layer

phpBB relaxes ACP access rules under adm/, and the login form there is the primary target for credential-stuffing bots. The ACP already re-prompts for your password when you enter it, which is a useful control, but you can put an entirely separate gate in front of the directory so unauthenticated visitors never reach the phpBB login form at all. cPanel's Directory Privacy tool (DirectAdmin calls it Password Protected Directories) creates an HTTP Basic Auth prompt backed by an .htpasswd file stored outside the web root. Point it at public_html/forum/adm, set a username and a strong password unrelated to your forum admin credentials, and every request to the control panel now requires two independent secrets.

If your connection comes from a stable address, IP allow-listing is even stronger. Create an .htaccess inside the adm/ directory:

<RequireAny>
    Require ip 203.0.113.45
</RequireAny>

Replace the sample address with your own — check it at any "what is my IP" service. Anyone connecting from a different address receives a 403 before phpBB even loads. Pair this with the ACP setting under Administration Control Panel > General > Server configuration > Security settings, where you should enable Validate user session IP against all four octets and set a short session length so a stolen cookie expires quickly. Also confirm that Force Two Letter ISO 639-1 language and referrer validation are left at their secure defaults; loosening them to fix a plugin problem usually just widens the CSRF surface.

Stopping registration and posting spam at the source

Open registration is where most phpBB abuse begins: bots create accounts to post link spam, seed signature farms, or probe for privilege escalation. The controls live under ACP > General > Board configuration > Spambot countermeasures. Switch the CAPTCHA to a genuine challenge — phpBB bundles a GD-based image CAPTCHA, and for higher-traffic boards the reCAPTCHA plugin is worth installing. Set the plugin to run on registration and, ideally, on the first few posts of new members. Under User registration settings, enable account activation by email so a valid inbox is required, and consider Admin activation for smaller communities where you can approve members by hand.

phpBB also supports flood control. Under Board configuration > Post settings set a Flood interval of 15 seconds or more and a sensible minimum characters per post, which frustrates scripted mass-posting. The Ban settings and the built-in Ban IP tool let you block ranges that repeatedly hit registration; combine this with the free StopForumSpam integration available as a phpBB extension to reject known abusive emails and addresses automatically. If your SMTP relay is being triggered by spam registrations, review your mail deliverability alongside these controls in our companion walkthrough on phpBB email delivery via SMTP.

You can throttle raw request volume against the registration URL with a lightweight rule in the board-root .htaccess that blocks empty or scripted user agents commonly used by bots:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
RewriteCond %{HTTP_USER_AGENT} (libwww|wget|python-requests|curl) [NC]
RewriteCond %{REQUEST_URI} (ucp\.php|posting\.php) [NC]
RewriteRule .* - [F,L]

Adding HTTP security headers and enforcing HTTPS

Browsers respect a set of response headers that reduce the impact of clickjacking, MIME sniffing, and mixed content, but phpBB does not emit them by default. Because you control .htaccess under LiteSpeed, you can add them account-wide for the board. Place the following in the board-root .htaccess:

<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" env=HTTPS
</IfModule>

The HSTS line should only be enabled once you have a valid certificate installed and the whole board loading over HTTPS, otherwise you can lock visitors out. Issue the certificate through cPanel Security > SSL/TLS Status (AutoSSL) or DirectAdmin SSL Certificates, then force HTTPS with a redirect ahead of phpBB's own rewrite block:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Finish inside the ACP by setting Server URL settings under Server configuration to the https:// address, enabling Cookie secure, and confirming the cookie domain matches your board so session cookies are never sent in the clear. A Content-Security-Policy is powerful but easy to break with third-party avatars and analytics, so introduce it only after auditing what your board loads. With config.php locked at 644, the installer removed, the ACP behind a second gate, spam countermeasures active, and these headers in place, your phpBB board presents a small and well-guarded surface to the traffic it will inevitably attract.