Docs LATEST

Security Hardening

Additional security measures beyond the production checklist.

Security

This page covers security measures beyond the basics in Production Checklist. Start there first.

HTTP Security Headers #

Add these headers via your web server:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
Header Purpose
X-Frame-Options Prevents clickjacking via iframes
X-Content-Type-Options Stops MIME type sniffing
X-XSS-Protection Legacy XSS filter (modern browsers)
Referrer-Policy Controls referrer information leakage

Content Security Policy #

CSP provides strong XSS protection by whitelisting content sources:

add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline';" always;

Adjust based on your needs:

  • External fonts: add font-src 'self' fonts.googleapis.com
  • External scripts: add domains to script-src
  • Inline scripts: use nonces instead of 'unsafe-inline'

HSTS (HTTP Strict Transport Security) #

Force browsers to always use HTTPS:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Only enable after confirming HTTPS works correctly - this is hard to undo.

Database User Separation #

Create separate users for runtime vs migrations:

-- Runtime user: minimal privileges
CREATE USER 'velvet_app'@'localhost' IDENTIFIED BY 'strong_password';
GRANT SELECT, INSERT, UPDATE, DELETE ON velvet_db.* TO 'velvet_app'@'localhost';

-- Migration user: schema changes
CREATE USER 'velvet_admin'@'localhost' IDENTIFIED BY 'different_password';
GRANT ALL ON velvet_db.* TO 'velvet_admin'@'localhost';

Use the admin user only for ./velvet migrate.

Database Connection Security #

  • Prefer Unix sockets over TCP for local connections
  • Require SSL for remote database connections
  • Never commit credentials to version control

Dependency Auditing #

Regularly check for known vulnerabilities:

composer audit

Run this in CI/CD pipelines and before deployments.

Secret Key Generation #

Generate strong random keys for sessions, API tokens, etc:

openssl rand -base64 32

Monitoring #

Watch for:

  • Unusual traffic spikes
  • Repeated failed login attempts
  • 404 probing patterns (e.g., /wp-admin, /phpmyadmin)
  • Error rate increases

Checklist #

  • Security headers configured
  • CSP policy defined
  • HSTS enabled (after HTTPS verified)
  • Database users separated by privilege
  • composer audit clean
  • Monitoring in place
  • Hidden files (.env, .git) blocked
  • Security headers configured
  • Database user has minimal privileges
  • Config cached (config:cache)
  • OPcache enabled
  • Dependencies updated and audited
  • Log rotation configured
  • WebCron protected (if enabled)