Hosting & Web Security

1. Project Goal

Build a structured, technically correct guide that teaches:

• How web hosting works
• How to deploy websites (static and dynamic)
• How to configure servers securely
• How to protect infrastructure from common attacks
• How to set up production-ready environments
• How to think about security like an engineer

Tone: Clear, practical, no fluff, no marketing language. Focus on real-world habits.

2. Hosting Fundamentals

What is Hosting

Hosting provides the infrastructure (servers, storage, network) to make websites accessible on the internet. A server is a computer that runs continuously, serving content to visitors.

Types of Hosting

Domain and DNS

A domain is a human-readable address (example.com). DNS (Domain Name System) translates domains to IP addresses.

IP Addresses

IPv4: 32-bit address (192.168.1.1). IPv6: 128-bit address (2001:0db8::1). Public IPs are routable on the internet; private IPs are for local networks.

Reverse Proxy

A server that sits between clients and backend servers. Handles SSL termination, load balancing, and caching. Common implementations: Nginx, Caddy, Traefik.

SSL/TLS

Transport Layer Security encrypts data between client and server. TLS 1.3 is current standard. Certificates are issued by Certificate Authorities (Let's Encrypt, free).

3. Beginner Deployment Paths

Path 1: GitHub Pages (Static Sites)

Free hosting for static websites directly from GitHub repositories.

Setup Steps

1. Create repository: username.github.io
2. Push HTML/CSS/JS files to main branch
3. Enable Pages in repository settings

Folder Structure

username.github.io/
├── index.html
├── css/
│   └── style.css
├── js/
│   └── app.js
└── assets/
    └── images/

Common Mistakes

• Repository name must match username exactly
• Index.html must exist in root or /docs folder
• Case sensitivity issues on file paths

Path 2: Vercel / Netlify

Platform-as-a-Service for frontend frameworks and static sites.

Vercel Deployment

# Install CLI
npm i -g vercel

# Login
vercel login

# Deploy
vercel --prod

Netlify Deployment

# Install CLI
npm install -g netlify-cli

# Login
netlify login

# Deploy
netlify deploy --prod --dir=build

Troubleshooting

• Build command must output to correct directory (dist/, build/)
• Environment variables set in dashboard, not committed
• Redirects require _redirects file or netlify.toml/vercel.json

Path 3: Basic VPS Deployment

Deploying to a virtual private server provides full control.

Prerequisites

• VPS from provider (DigitalOcean, Linode, Hetzner, AWS Lightsail)
• SSH client (OpenSSH on Linux/Mac, PuTTY on Windows)
• Domain name (optional but recommended)

Connection

# Default connection (password auth - temporary)
ssh root@your_server_ip

# Verify host key fingerprint matches provider dashboard

4. VPS Production Setup Guide

Step 1: Initial Server Access

# Connect as root (only for initial setup)
ssh root@server_ip

# Update system packages
apt update && apt upgrade -y

# Install essential tools
apt install -y curl wget vim ufw fail2ban

Step 2: Create Non-Root User

# Create user
adduser deploy

# Add to sudo group
usermod -aG sudo deploy

# Switch to new user
su - deploy

# Verify sudo access
sudo whoami

Step 3: SSH Key Authentication

On local machine:

# Generate SSH key pair (if not exists)
ssh-keygen -t ed25519 -C "[email protected]"

# Copy public key to server
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@server_ip

Step 4: Secure SSH Configuration

# Edit SSH config
sudo nano /etc/ssh/sshd_config

# Modify these lines:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
MaxAuthTries 3

# Restart SSH
sudo systemctl restart sshd

Step 5: Configure Firewall (UFW)

# Default deny
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow SSH (before enabling)
sudo ufw allow 22/tcp

# Allow HTTP/HTTPS
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Enable firewall
sudo ufw enable

# Check status
sudo ufw status verbose

Step 6: Install Docker

# Remove old versions
sudo apt remove docker docker-engine docker.io

# Install dependencies
sudo apt install -y apt-transport-https ca-certificates gnupg lsb-release

# Add Docker GPG key
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

# Add repository
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Install Docker
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io

# Add user to docker group
sudo usermod -aG docker deploy

# Verify
docker --version

Step 7: Application Deployment

Create application structure:

mkdir -p ~/app
cd ~/app

# Create Dockerfile
cat > Dockerfile << 'EOF'
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
USER node
CMD ["node", "server.js"]
EOF

Step 8: Reverse Proxy with Caddy

# Install Caddy
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

# Configure Caddyfile
sudo nano /etc/caddy/Caddyfile

example.com {
    reverse_proxy localhost:3000
    encode gzip
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
        X-XSS-Protection "1; mode=block"
    }
}

# Reload Caddy
sudo systemctl reload caddy

# Enable auto-start
sudo systemctl enable caddy

Step 9: SSL with Let's Encrypt (Caddy handles automatically)

Caddy automatically provisions and renews certificates. For manual certbot with Nginx:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

# Auto-renewal test
sudo certbot renew --dry-run

Step 10: Process Management

Create systemd service for application:

sudo nano /etc/systemd/system/myapp.service

[Unit]
Description=My Application
After=network.target

[Service]
Type=simple
User=deploy
WorkingDirectory=/home/deploy/app
ExecStart=/usr/bin/docker run --rm -p 3000:3000 myapp:latest
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable myapp
sudo systemctl start myapp

# Check logs
sudo journalctl -u myapp -f

Step 11: Backup Strategy

# Install restic for backups
sudo apt install restic

# Initialize backup repository
restic init --repo /backup/repo

# Create backup script
cat > ~/backup.sh << 'EOF'
#!/bin/bash
export RESTIC_PASSWORD="your-secure-password"
restic -r /backup/repo backup /home/deploy/app/data
restic -r /backup/repo forget --keep-last 7 --keep-daily 30
EOF

chmod +x ~/backup.sh

# Add to crontab (daily at 2 AM)
0 2 * * * /home/deploy/backup.sh

5. Security Practices

Never Do This

• SSH as root for routine operations
• Leave password authentication enabled
• Commit .env files to version control
• Expose databases publicly (MongoDB, Redis, PostgreSQL)
• Hardcode API keys in source code
• Leave unnecessary ports open
• Run applications as root
• Disable firewall for debugging

Always Do This

• Use SSH key authentication exclusively
• Implement strict firewall rules (deny all, allow specific)
• Deploy Fail2ban for intrusion prevention
• Enforce HTTPS with valid certificates
• Apply security updates automatically or regularly
• Enable comprehensive logging
• Maintain tested backup procedures
• Use principle of least privilege

Fail2ban Configuration

sudo apt install fail2ban

sudo tee /etc/fail2ban/jail.local << 'EOF'
[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 3
backend = systemd

[sshd]
enabled = true
port = 22
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
EOF

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

# Check status
sudo fail2ban-client status sshd

Automatic Updates

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

6. How You Get Hacked

7. CI/CD & DevOps Basics

GitHub Actions Deployment

Create .github/workflows/deploy.yml:

name: Deploy to Production

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Setup Node
        uses: actions/setup-node@v3
        with:
          node-version: '18'
          
      - name: Install dependencies
        run: npm ci
        
      - name: Run tests
        run: npm test
        
      - name: Build
        run: npm run build
        
      - name: Deploy to server
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USERNAME }}
          key: ${{ secrets.SSH_KEY }}
          script: |
            cd /home/deploy/app
            git pull origin main
            docker build -t myapp:latest .
            docker stop myapp || true
            docker rm myapp || true
            docker run -d --name myapp -p 3000:3000 myapp:latest

Secret Management

• Store secrets in GitHub Settings > Secrets and Variables
• Never log secrets in CI output
• Rotate credentials regularly
• Use short-lived tokens where possible

Environment Variables

# Production .env file (not committed)
NODE_ENV=production
DATABASE_URL=postgresql://user:pass@localhost/db
JWT_SECRET=use-random-256-bit-string-here
API_KEY=external-service-key

Rate Limiting

Implement at reverse proxy or application level:

# Nginx rate limiting
limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;

server {
    location /api/ {
        limit_req zone=one burst=20 nodelay;
    }
}

Logging

# Centralized logging with journald
sudo journalctl -u myapp -f -n 100

# Structured logging format (JSON)
{"timestamp":"2024-01-01T00:00:00Z","level":"error","message":"DB connection failed","request_id":"uuid"}

Monitoring Concepts

• Prometheus: Metrics collection and alerting
• Grafana: Visualization and dashboards
• Key metrics: CPU, memory, disk, request latency, error rates
• Uptime monitoring: External health checks (UptimeRobot, Pingdom)

Cloudflare Basics

# DNS configuration
Type: A
Name: example.com
Content: your_server_ip
Proxy status: Proxied (orange cloud)

# Always Use HTTPS: On
# Security Level: Medium
# Browser Cache TTL: 4 hours

8. Production Checklist

Server Security

• Non-root user created and configured
• SSH root login disabled
• Password authentication disabled
• SSH key authentication enforced
• Firewall enabled (UFW/iptables)
• Fail2ban installed and active
• Automatic security updates enabled
• Unnecessary services disabled

Application Security

• HTTPS enforced (HSTS enabled)
• SSL certificate valid and auto-renewing
• Security headers configured
• Rate limiting implemented
• Input validation on all endpoints
• Authentication and authorization tested
• Secrets not in code repository
• Dependencies scanned for vulnerabilities

Data Protection

• Database not exposed to internet
• Database authentication enabled
• Regular backups configured
• Backup restoration tested
• Encryption at rest (if applicable)
• Encryption in transit (TLS 1.2+)

Monitoring & Maintenance

• Logging configured and accessible
• Log rotation enabled
• Health checks implemented
• Monitoring alerts configured
• Incident response plan documented
• Documentation current

9. Learning Paths

10. Common Beginner Mistakes

Configuration Errors

• Mistake: Editing production configs directly without version control
• Solution: Use configuration management or at minimum document changes
• Mistake: Testing in production
• Solution: Maintain separate staging environment
• Mistake: Hardcoding configuration values
• Solution: Environment variables for all environment-specific values

Security Oversights

• Mistake: "Security through obscurity" (hoping attackers won't find it)
• Solution: Assume attacker knows system architecture; implement defense in depth
• Mistake: Ignoring security updates
• Solution: Subscribe to security advisories; patch within 24-48 hours
• Mistake: Storing passwords in plain text
• Solution: Use bcrypt/Argon2 for hashing; never store recoverable passwords

Operational Errors

• Mistake: No backup verification
• Solution: Monthly restoration drills
• Mistake: Running everything as root
• Solution: Principle of least privilege; separate service accounts
• Mistake: No monitoring or alerting
• Solution: Monitor disk, memory, CPU; alert on anomalies

Development Practices

• Mistake: Committing secrets to git
• Solution: Use git-secrets pre-commit hook; scan repositories
• Mistake: No dependency management
• Solution: Lock files committed; automated vulnerability scanning
• Mistake: Ignoring error handling
• Solution: Structured error responses; no stack traces to client

11. Additional Attack Vectors

12. Secrets Management

Never store secrets in code or Docker images. Use a dedicated secrets manager:

Tools

• HashiCorp Vault: Self-hosted, dynamic secrets, fine-grained policies. Best for advanced setups.
• Doppler: SaaS, syncs .env automatically per environment. Easy to start with.
• AWS Secrets Manager / Parameter Store: Native if already on AWS. Supports automatic rotation.
• Infisical: Open-source alternative to Doppler, self-hostable.

Runtime Injection Pattern

# Docker: inject at runtime, never baked in
docker run -e DATABASE_URL="$DATABASE_URL" -e JWT_SECRET="$JWT_SECRET" myapp:latest

# Or use Docker secrets (Swarm/Compose)
echo "my_secret_value" | docker secret create db_password -

# .gitignore — always include:
.env
.env.local
.env.production
*.key
*.pem

Scan for Leaked Secrets

# Install trufflehog (scans git history)
pip install trufflehog
trufflehog git file://. --only-verified

# Or gitleaks
gitleaks detect --source . -v

# Pre-commit hook with detect-secrets
pip install detect-secrets
detect-secrets scan > .secrets.baseline
# Add as pre-commit hook to prevent future commits

13. Content Security Policy (CSP)

CSP is one of the most powerful defenses against XSS. Many guides skip it — don't.

Basics

# Nginx — add to server block
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; connect-src 'self'; frame-ancestors 'none'; base-uri 'self'; form-action 'self';" always;

# Report-only mode (test without breaking things)
add_header Content-Security-Policy-Report-Only "default-src 'self'; report-uri /csp-report;" always;

Key Directives

⚠ Warning: Never use unsafe-inline or unsafe-eval in script-src — this defeats the purpose of CSP entirely. Use nonces instead.