Web Developer Security Guide: Real-World Linux Server Problems and Practical Fixes

If you build or deploy websites on Linux servers, security isn’t optional — it’s your responsibility. And unlike theory-heavy security guides, this article focuses on real problems that web developers actually face, along with clear, practical fixes you can apply right away.

Let’s jump straight in 👇

🧩 Problem #1 — Your Website Is Still Using HTTP (Not HTTPS)

Why this is a problem

If your site loads over HTTP, anyone on the same network can intercept:

• logins
• cookies
• admin sessions

And modern browsers will even warn users that your site is “Not Secure.”

Not a great first impression.

✅ How To Fix It (Enable HTTPS with Let’s Encrypt)

If you use NGINX:

Install Certbot:

sudo apt install certbot python3-certbot-nginx

Request the certificate:

sudo certbot --nginx

Enable auto-renew:

sudo systemctl enable certbot.timer

Done. Your site now uses HTTPS.

✔ data is encrypted
✔ browser warnings disappear
✔ SEO improves

🧩 Problem #2 — Your SSH Login Is Getting Brute-Forced

How you know this is happening

Check your auth log:

cat /var/log/auth.log

If you see something like this:

Failed password for root from 185.223.11.6

over and over again — congratulations, bots have found you.

✅ Fix #1 — Disable Root + Password Login

Open your SSH config:

sudo nano /etc/ssh/sshd_config

Set:

PermitRootLogin no
PasswordAuthentication no

Restart SSH:

sudo systemctl restart ssh

Now only SSH keys can log in.

✅ Fix #2 — Install Fail2Ban

sudo apt install fail2ban

Start and enable:

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Now repeated failed logins = automatic ban.

🧩 Problem #3 — People Can See Your Folder Contents

The problem

If someone visits:

yourdomain.com/uploads/

And they see a file list?

That’s bad. Really bad.

They can discover:

✔ hidden files
✔ backups
✔ scripts
✔ sensitive data

✅ Fix It — Disable Directory Listing

NGINX

Add:

autoindex off;

Restart:

sudo systemctl restart nginx

Apache

Add:

Options -Indexes

Problem solved.

🧩 Problem #4 — Your Server Version Is Publicly Visible

Why this matters

If your headers say:

Server: nginx/1.24

Apache/2.4.57 Ubuntu

Hackers immediately know which vulnerabilities to try.

✅ Fix

NGINX

Add:

server_tokens off;

Apache

Add:

ServerSignature Off
ServerTokens Prod

Restart your server.

🧩 Problem #5 — PHP Errors Are Shown to Users

Why this is dangerous

Error output can reveal:

• paths
• queries
• system details
• code structure

Great for debugging.
Terrible for production.

✅ Fix — Disable PHP Display Errors

Edit php.ini:

display_errors = Off
log_errors = On

Restart PHP-FPM:

sudo systemctl restart php8.2-fpm

Now errors go to logs, not users.

🧩 Problem #6 — Your File Permissions Are Too Loose

If you see permissions like:

That means:

✔ anyone can read
✔ anyone can modify
✔ anyone can execute

This is practically an invitation.

✅ Fix — Use Safe Defaults

Folders:

Files:

Sensitive files (.env):

Run:

find /var/www/html -type f -exec chmod 644 {} \;
find /var/www/html -type d -exec chmod 755 {} \;
chmod 600 /var/www/html/.env

🧩 Problem #7 — Your Database Is Accessible From the Internet

Why this is a disaster waiting to happen

If MySQL or PostgreSQL is listening on:

0.0.0.0

Anyone can try connecting. And people will.

✅ Fix — Bind to Localhost Only

bind-address = 127.0.0.1

Restart DB service.

Now only local connections work.

🧩 Problem #8 — Admin Tools Are Publicly Accessible

Examples:

domain.com/phpmyadmin
domain.com/adminer.php
domain.com/panel

Bots scan for these constantly.

✅ Fix — Restrict Access

Example (UFW firewall):

ufw allow from 1.2.3.4 to any port 22

Or protect with basic auth / VPN.

🧩 Problem #9 — Debug Mode Is Enabled in Production

This leaks things like:

• stack traces
• queries
• API keys
• env values

✅ Fix — Separate Environments

Laravel:

APP_ENV=production
APP_DEBUG=false

Node.js:

NODE_ENV=production

Never deploy with debug mode on.

🧩 Problem #10 — You Don’t Have Backups

And you only realize when it’s too late.

✅ Fix — Automate Backups

Database:

mysqldump -u root -p dbname > backup.sql

Files:

tar -czf backup.tar.gz /var/www/

Store backups:

✔ off-server
✔ off-cloud
✔ somewhere safe

✅ Final Security Checklist for Web Developers

Before going live, make sure:

✔ HTTPS enabled
✔ SSH hardened
✔ Firewall active
✔ Fail2Ban installed
✔ PHP errors hidden
✔ Safe file permissions
✔ Database not public
✔ Admin access restricted
✔ Debug mode disabled
✔ Backups running
✔ System updated
✔ CDN / WAF enabled