Security Hardening Guide

People building websites often fall into the trap of treating security as "install a WAF before launch and you're done." But a WAF is just the outermost layer; real security problems usually hide in configuration, permissions, and coding habits. Here's a hardening path you can actually follow, from prompts to system config to incident response.

AI Prompt Template

If you're not sure where to start, let an AI draft a plan, then verify it item by item:

Create a security hardening plan.
- Site Type: [Corporate/E-commerce/Blog/App]
- Tech Stack: [PHP/Node.js/Python] | OS: [Ubuntu/CentOS]

Output: SSH/firewall config, SSL/TLS best practices, WAF, backup strategy, XSS/CSRF/SQLi protection.

Nginx Security Headers

Hiding the version banner and capping request body size is the cheapest hardening you can do:

server_tokens off;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
client_max_body_size 50M;

A fuller set of response headers also covers referrer policy and content security policy:

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;
add_header Content-Security-Policy "default-src 'self'; img-src 'self' data: https:;" always;

Server Init Security Checklist

  • Disable root SSH login
  • Change default SSH port
  • Enable UFW: allow 80,443,22 only
  • Install fail2ban
  • Enable automatic security updates

### Automatic Backup Script

Backups are the last safety net. This script can run daily via cron:

```bash
#!/bin/bash
WEBSITE_DIR=${1:-/var/www/html}
BACKUP_DIR=${2:-/backups/web}
DATE=$(date +%Y%m%d_%H%M%S)
mkdir -p "$BACKUP_DIR"
tar -czf "${BACKUP_DIR}/backup_${DATE}.tar.gz" "$WEBSITE_DIR"
echo "Backup complete"

Two notes: keep backups in a directory the public can't reach, and store a second copy off-site — otherwise an intruder can delete your backups along with the site.

Security Is a Design Choice, Not a Feature

Many people think website security means "install a WAF." But security can't be bolted on — it has to be built into every design decision.

The simplest principle: never trust user input, always use least privilege.

Three Layers of Defense

Layer 1: Network Perimeter

This is where most people start, and it blocks about 80% of automated attacks:

  • Open only necessary ports (80, 443, SSH)
  • Use SSH keys, not passwords
  • Install fail2ban for brute force protection
  • Enable UFW or iptables

Layer 2: Application Security

This is where actual damage happens:

SQL Injection: Use parameterized queries or an ORM. Never concatenate SQL strings.

XSS: Escape all output rendered to HTML. Frontend frameworks usually handle this, but be careful when manipulating the DOM directly.

CSRF: Generate a unique token for every form and validate on submission.

File Uploads: Disable script execution in upload directories. Restrict file types and sizes. Consider using a separate domain or cloud storage.

Layer 3: Data Security

  • Use strong random passwords for databases, one per service
  • Encrypt backups before storing them
  • Never store backups in publicly accessible directories

HTTPS Configuration

server {
    listen 443 ssl http2;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:...;
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;
}

Test your configuration at ssllabs.com. Aim for grade A or better.

Incident Response

Even with all precautions, breaches can happen. What matters is how you respond:

  1. Detect: Monitoring or user reports flag an anomaly
  2. Isolate: Remove affected services from the cluster
  3. Analyze: Review logs, determine breach path and data impact
  4. Fix: Patch vulnerabilities, reset all affected credentials
  5. Recover: Restore from a clean backup
  6. Review: Post-mortem to update security policies

Run a tabletop exercise every six months — 2 hours in a conference room walking through each step reveals gaps you didn't know you had.

A Practical Scenario: 15 Minutes Before Launch

Say you just deployed a new site to a Tencent Cloud server and DNS has propagated. Fifteen minutes before launch, do three quick things: run nmap -p- your-ip to check for unexpected open ports; audit database default accounts and weak passwords; and add a second-factor check to the admin login. Most "got defaced three days after launch" incidents trace back to one of these three being skipped.

Frequently Asked Questions

Do free certificates differ much from paid ones? For the vast majority of sites, a free Let's Encrypt certificate is sufficient — the key is setting up automatic renewal. Paid certificates mainly add a longer validity period and commercial support, not stronger encryption.

What do I do under a CC (challenge-collapse) attack? First identify the traffic pattern: if a single IP keeps hammering one endpoint, block the IP and add rate limiting; if it's distributed bandwidth flooding, a single server won't hold up — enable DDoS protection or CDN scrubbing. Keep logs and monitoring in place so you can tell the difference quickly.

Can a WAF replace code-level defenses? No. A WAF blocks known, signature-heavy attacks; injection points, privilege escalation, and sensitive-data leaks in your code often pass right through it. The two are complementary, not alternatives.

Passwords or 2FA first? Do the two free things first: change default passwords and enable two-factor authentication on admin accounts. They cost almost nothing and block the vast majority of credential-stuffing and weak-password attacks.

One Thing to Do Today

Security isn't a purchased product. It's a habit. Start with one thing: check your server for open test ports or default passwords that haven't been changed.

References: OWASP Top Ten https://owasp.org/www-project-top-ten/ , Mozilla Web Security Guidelines https://infosec.mozilla.org/guidelines/web_security , Let's Encrypt docs https://letsencrypt.org/docs/