The 10 Most Dangerous Hosting Security Settings You Can Change Today

Most dangerous hosting security settings are the ones your control panel enabled for you, and you can change them today without waiting for support. The web hosting security settings to change are the defaults that prioritize convenience over isolation, and the fix is usually one config line or one terminal command away.

1. Directory Listing Is Still On

If your server returns an HTML index when a directory has no index.html or index.php, you are leaking file names, backup files, and sometimes source code. Apache enables this with Options Indexes, and Nginx does it with autoindex on;. Attackers use directory listings to find .env, backup.zip, or config.old files that your app never meant to expose.

For Apache, put this in your virtual host or .htaccess:

Options -Indexes

For Nginx, inside your server block:

autoindex off;

Then reload the web server. Test by visiting a folder that has no index file. You should see a 403 Forbidden response, not a file list.

2. Default SSH Port and Password Authentication

Port 22 is scanned constantly, and password authentication means a brute force script only needs a weak password. Change the SSH port to something above 1024, and disable password login entirely if you have an SSH key. Edit /etc/ssh/sshd_config and set these:

Port 2222
PasswordAuthentication no
PubkeyAuthentication yes

Before you reload SSH, make sure your public key is in ~/.ssh/authorized_keys and that you can log in on the new port from a second terminal. Then run sudo systemctl reload sshd. If you lock yourself out, your hosting provider’s console access is your recovery path, so test carefully.

3. Exposed Server Tokens and Version Headers

Your server tells the world what software and version it runs. Apache sends Server and X-Powered-By headers, and Nginx sends Server. A known version number lets an attacker match it against public vulnerability databases. Hide the version but keep the server name generic.

For Apache, in your main config or virtual host:

ServerTokens Prod
ServerSignature Off

For Nginx, in http block:

server_tokens off;

Then reload. Check with curl -I https://yourdomain.com. You should see Server: Apache or Server: nginx with no version number after it.

4. PHP Error Reporting Exposed to Visitors

When PHP displays errors on screen, it shows file paths, database credentials, and stack traces. That is a gift to anyone probing your site. Set display_errors to off in production, but keep logging on so you can still debug. In your php.ini or a .user.ini file in your web root:

display_errors = Off
log_errors = On
error_log = /var/log/php-errors.log

If you use a framework like Laravel or WordPress, also check its own error settings. For WordPress, add this to wp-config.php:

define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);
define('WP_DEBUG_LOG', true);

Your application logs will still capture errors, but the public will not see them.

5. Unrestricted File Uploads and Executable Scripts

Many hosting setups let you upload any file type to any directory, and then execute scripts from those directories. That turns a simple upload form into a remote code execution vector. The fix is to restrict execution in directories that should only hold images or static assets. For Apache, in an .htaccess inside your uploads directory:

<FilesMatch "\.(php|pl|py|cgi|sh)$">
  Require all denied
</FilesMatch>

For Nginx, use a location block that disables PHP processing for that path:

location ~* /uploads/.*\.(php|pl|py)$ {
    deny all;
}

Then test by trying to access a PHP file you placed in that directory. It should return 403, not execute.

6. Weak Cookie Security Flags

Session cookies without Secure and HttpOnly flags can be stolen over plain HTTP or read by JavaScript. The Secure flag forces the cookie to be sent only over HTTPS, and HttpOnly prevents client-side scripts from accessing it. If your app sets cookies manually, add these flags. For PHP, in php.ini:

session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax

For a custom header, make sure your app sends something like this:

Set-Cookie: sessionid=abc123; HttpOnly; Secure; SameSite=Lax

Check your site’s response headers with curl -I or your browser’s developer tools. If you see a session cookie without those flags, your framework or application is overriding the server default, so fix it in the application config, not just the server.

7. Open Database Ports to the Internet

MySQL, PostgreSQL, and Redis often listen on 0.0.0.0 because the hosting installer set them that way. That means anyone on the internet can attempt a connection. Unless your application runs on a different machine, bind the database to localhost only. For MySQL, edit /etc/mysql/mysql.conf.d/mysqld.cnf and set:

bind-address = 127.0.0.1

For PostgreSQL, edit postgresql.conf:

listen_addresses = 'localhost'

Then restart the database service. Verify with ss -tlnp | grep 3306 or ss -tlnp | grep 5432. You should see 127.0.0.1 in the address column, not * or 0.0.0.0.

8. Default Admin Credentials on Control Panels and Databases

Your hosting control panel, database admin tool, and even your CMS often ship with a default username and password. The first thing an automated scanner does is try admin and password or root and root. Change every default credential immediately, and use a unique password per service. For MySQL, run this from the command line:

ALTER USER 'root'@'localhost' IDENTIFIED BY 'your-new-strong-password';
FLUSH PRIVILEGES;

Do the same for your control panel login, your FTP account, and your CMS admin account. If your provider gave you a temporary password, change it before you upload any real content.

9. Missing Security Headers in Your Web Server Response

Headers like X-Frame-Options, X-Content-Type-Options, and Content-Security-Policy prevent clickjacking, MIME sniffing, and injected scripts. They are not enabled by default on most hosting setups. Add them at the server level so every response gets them. For Apache, in your virtual host:

Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"

For Nginx, in your server block:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Reload and test with curl -I. You should see all three headers in the response. A Content-Security-Policy header is more complex, so start with the simple ones and add CSP only after you understand what your site loads.

10. Unused Services and Open Ports

Every listening port is a potential entry point. FTP, Telnet, and even a debug port left open by a forgotten service are common on shared and VPS hosting. Run ss -tlnp and look at what is listening. If you see 21 (FTP) and you use SFTP instead, disable the FTP service. If you see 25 (SMTP) and you do not send mail from this server, stop that service too. For each service you do not recognize, check its process name with ps aux | grep <name> and then disable it with sudo systemctl disable --now <service>.

Do not forget IPv6. Check ss -tlnp6 as well, because a service bound to :: is reachable over IPv6 even if your IPv4 rules are strict.

What to do next

Start with the three changes that give you the most protection for the least effort: disable directory listing, turn off PHP error display, and change your SSH port with key-only login. Then work through the rest over the next week. After each change, test the affected service from a browser and a terminal. Keep a list of what you changed and when, so you can revert quickly if something breaks. If you are on shared hosting, some of these settings will be locked by your provider, so contact support and ask specifically which of these directives they allow you to override. The goal is not to become an expert overnight, it is to remove the low hanging fruit that automated scanners find first.