Security Hardening
Additional security measures beyond the production checklist.
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 auditclean - 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)