FluxBB is deliberately lightweight, and that minimalism carries a security cost: the installer does not lock down file permissions, does not restrict access to the admin directory beyond a login check, and sends no modern HTTP security headers. On a shared LiteSpeed server your account runs under CloudLinux with your own user context, so the fixes below live entirely inside your hosting account. You never touch server-wide settings, and every step uses cPanel Jupiter or DirectAdmin Evolution, the File Manager, phpMyAdmin, and the FluxBB AdminCP.

The most common real-world incidents on FluxBB boards trace back to three areas. First, the config.php file containing your database credentials is frequently left at permissions that let other processes read it. Second, the /admin/ path is reachable by anyone who knows the URL, which invites credential stuffing against your administrator account. Third, spam registrations flood the user table because the default anti-bot measures are weak. Each of these is fixable without a single privileged command.

Locking down config.php and directory permissions

Your FluxBB root sits under /home/USERNAME/public_html (or a subfolder like /home/USERNAME/public_html/forum if you installed into a directory). The single most sensitive file is config.php, which stores the database name, user, and plaintext password. On a correctly configured account PHP reads this file as your user, so it does not need read access for anyone else.

Open cPanel and go to Files > File Manager, navigate to your FluxBB root, right-click config.php and choose Change Permissions. Set it to 0600 (owner read and write only). In DirectAdmin the equivalent is System Info & Files > File Manager, then the permissions column next to the file. If your setup runs PHP via LiteSpeed with the file owned by your user, 0600 works. Should the forum stop loading after this change and the local error_log in the FluxBB root shows a permission-denied entry on config.php, raise it to 0644 as a fallback, but 0600 is the target.

Directories and other PHP files follow a standard pattern. Set all directories to 0755 and all PHP files to 0644. The cache/ and img/avatars/ directories need to be writable by FluxBB, so keep them at 0755 (not 0777). A world-writable 0777 directory is a frequent malware entry point because any compromised script on the server could drop a file there. If a previous installer or migration left folders at 0777, correct them now. You can apply permissions recursively in cPanel File Manager by selecting a folder, choosing Change Permissions, and ticking the recurse option, but apply the file and folder values separately so you do not accidentally make PHP files executable.

Add a top-level protection rule so the config and cache are never served directly even if a misconfiguration exposes them. In your FluxBB root create or edit .htaccess and add:

<FilesMatch "config\.php$">
    Require all denied
</FilesMatch>

# Block direct access to the cache directory contents
RedirectMatch 403 ^/cache/.*$

The Require all denied directive is the Apache 2.4 syntax that LiteSpeed honors. Even though PHP still includes config.php internally, a direct browser request to it now returns 403.

Protecting the admin path and strengthening authentication

FluxBB places its control panel at /admin/ with the entry file admin_index.php and related admin_*.php scripts in the root. Anyone can load the login form, so the board is only as safe as your administrator password. Add a second authentication layer using cPanel's Directory Privacy, which writes an .htpasswd challenge in front of the folder.

In cPanel go to Files > Directory Privacy (called Password Protect Directories in some themes), browse to the admin folder, tick "Password protect this directory," give it a label, and create a user with a strong password. In DirectAdmin the same feature is Account Manager > Password Protected Directories. Because FluxBB's admin scripts actually live in the root as admin_index.php rather than inside /admin/ in older releases, confirm your version's layout in File Manager first. If the admin logic is in root-level files, protect those with a targeted rule instead:

<FilesMatch "^admin_.*\.php$">
    AuthType Basic
    AuthName "Restricted Admin"
    AuthUserFile "/home/USERNAME/.htpasswds/admin/passwd"
    Require valid-user
</FilesMatch>

Replace /home/USERNAME/ with your real home path, which you can copy from the File Manager address bar. The cPanel Directory Privacy tool generates the .htpasswds file for you, so the cleanest approach is to create the credential through the UI and then point the AuthUserFile path at the file it produced.

Inside the FluxBB AdminCP itself, tighten the account layer. Go to Admin > Users and confirm your administrator username is not the predictable admin; create a fresh administrator with a distinct name and demote or remove the old one. Under Admin > Options > Registration, review the password requirements. FluxBB stores password hashes, but a long passphrase remains your best defense against brute force behind the Basic Auth wall. If your PHP version is old, use cPanel's MultiPHP Manager or the PHP Selector to move the domain to a supported branch (PHP 7.4 or newer where your FluxBB version allows), since current interpreters ship stronger hashing defaults and receive security patches.

Cutting spam registration and adding HTTP security headers

Automated registration spam is the highest-volume attack most small boards face. FluxBB includes a basic anti-bot question, and you should enable and customize it. In the AdminCP go to Admin > Options > Registration and turn on "Require visual confirmation" if your build offers it, then set a custom challenge phrase that bots trained on default FluxBB text will not answer. Set "Allow new registrations" to require administrator approval if your community is small, and enable email verification so throwaway addresses are filtered. Under Admin > Censoring you can also block links and known spam keywords to reduce post-registration abuse.

Complement this at the web-server layer. Add a rule in the root .htaccess that blocks requests to the registration script when they arrive without a referring page, a pattern typical of scripted signups:

RewriteEngine On
RewriteCond %{REQUEST_URI} register\.php$ [NC]
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?yourdomain\.com [NC]
RewriteRule .* - [F]

Finally, FluxBB sends none of the browser hardening headers that mitigate clickjacking, MIME sniffing, and mixed content. Add them once in the 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"
</IfModule>

Only add the Strict-Transport-Security line once your board is fully served over HTTPS, which you can confirm after issuing a free AutoSSL certificate in cPanel under Security > SSL/TLS Status. Pair HSTS with a canonical HTTPS redirect so mixed-content warnings disappear. After each .htaccess change, load the forum and watch the local error_log in the FluxBB root: a malformed directive produces a 500 error, and the log entry names the exact line so you can correct it in File Manager without guessing.