Security Hardening Guide

AI Prompt Template

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

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


## 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.

## 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.