Web security headers + HSTS + CSP

The article provides a comprehensive technical guide on implementing web security headers, HSTS, and CSP for managing over 130 production client sites on self-managed Linux infrastructure. It emphasizes that security directly impacts SEO performance, as compromised sites lose rankings, trigger browser warnings, and require months of recovery work. The guide includes specific configuration examples for SSL/TLS certificates via Let's Encrypt, Nginx HTTPS setup, and security header implementation to maintain both user trust and search engine ranking.

Originally published atPart of ThatDevPro's open SEO + AI framework library. thatdevpro.com . ThatDevPro is an SDVOSB-certified veteran-owned web + AI engineering studio. Open-source AI citation toolkit: github.com/Janady13/aio-surfaces . HTTPS, Headers, Authentication, WAF, Hardening, Incident Response, and the Security Posture Required to Maintain Search Trust A comprehensive reference for web security across the sites Joseph manages. Security is a baseline expectation in 2026 — Google explicitly considers HTTPS a ranking factor modest , security issues trigger manual actions, browser warnings destroy conversion rates, and breach incidents create permanent brand damage. 1. Document Purpose Security is often treated as separate from SEO/marketing concerns, but the disciplines significantly overlap. Hacked sites lose rankings, get flagged in browsers as dangerous, drive away users, generate manual actions in GSC, and require months of recovery work. Sites with poor security signals lose trust both with users and with search engines. For Joseph's specific situation managing 130+ production client sites on self-managed Linux infrastructure, security discipline is foundational. A single compromised client site affects the broader hosting environment. WordPress sites particularly attract attack attempts continuously. This framework specifies security implementation across the full stack — server, application, content, and operational dimensions. 1.1 Required Tools - SSL Labs — ssllabs.com/ssltest/ — SSL/TLS configuration testing - Mozilla Observatory — observatory.mozilla.org — security headers analysis - Security Headers — securityheaders.com — header analysis - WPScan — WordPress vulnerability scanner - OWASP ZAP — application security scanner - Wordfence / Sucuri / Patchstack — WordPress security platforms - Cloudflare — WAF and DDoS protection - Let's Encrypt / acme.sh — free SSL certificates 2. HTTPS Implementation 2.1 SSL Certificate Management ssl certificate management: certificate options: lets encrypt: cost: "Free" validity: "90 days auto-renew " best for: "Most sites; commodity SSL" automation: "Certbot, acme.sh" paid dv certificates: cost: "$10-100/year" validity: "1-2 years" best for: "Sites preferring longer validity" benefit: "Sometimes faster issuance" extended validation: cost: "$100-500+/year" validity: "1-2 years" best for: "Financial, e-commerce with high trust requirements" note: "Browser address bar treatment reduced; less differentiation than years past" multi domain strategies: san certificates: description: "Multiple domains in single certificate" use case: "Multiple related domains" wildcard certificates: description: "Covers .example.com subdomains" use case: "Many subdomains" note: "Doesn't cover apex; need separate or SAN with apex" multi san: description: "Multiple unrelated domains in one certificate" use case: "Convenience; fewer certificates to manage" 2.2 Let's Encrypt Implementation For Joseph's Debian/Nginx setup managing 130+ sites: Install certbot apt install certbot python3-certbot-nginx Get certificate for single site certbot --nginx -d example.com -d www.example.com Auto-renewal typically configured by certbot install systemctl status certbot.timer Manual renewal test certbot renew --dry-run For mass renewal management: Renew all certificates certbot renew --quiet Should be in cron or systemd timer Default: twice daily check, renews when within 30 days of expiry 2.3 Nginx HTTPS Configuration Strong default Nginx HTTPS configuration: server { listen 443 ssl http2; listen :: :443 ssl http2; server name example.com www.example.com; SSL Certificate ssl certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl certificate key /etc/letsencrypt/live/example.com/privkey.pem; Modern SSL Configuration ssl protocols TLSv1.2 TLSv1.3; ssl ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384'; ssl prefer server ciphers off; ssl session cache shared:SSL:10m; ssl session timeout 10m; OCSP Stapling ssl stapling on; ssl stapling verify on; ssl trusted certificate /etc/letsencrypt/live/example.com/chain.pem; resolver 1.1.1.1 8.8.8.8 valid=300s; Security Headers see Section 3 add header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; ... rest of configuration } Redirect HTTP to HTTPS server { listen 80; listen :: :80; server name example.com www.example.com; return 301 https://$host$request uri; } 2.4 SSL Testing After implementation, verify with SSL Labs ssllabs.com/ssltest/ : - Target: A or A+ grade - Issues to fix: protocol weaknesses, weak ciphers, missing OCSP, certificate chain issues 3. Security Headers Security headers add layers of browser-enforced protection. 3.1 Complete Security Headers Strict-Transport-Security HSTS Forces HTTPS, prevents downgrade attacks add header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; X-Frame-Options Prevents clickjacking via iframe embedding add header X-Frame-Options "SAMEORIGIN" always; X-Content-Type-Options Prevents MIME sniffing add header X-Content-Type-Options "nosniff" always; Referrer-Policy Controls referrer information sent add header Referrer-Policy "strict-origin-when-cross-origin" always; Permissions-Policy formerly Feature-Policy Controls browser features add header Permissions-Policy "geolocation= , microphone= , camera= " always; Content-Security-Policy most complex; see below add header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data: https:; connect-src 'self' https://www.google-analytics.com; frame-ancestors 'self'; base-uri 'self'; form-action 'self';" always; Cross-Origin policies add header Cross-Origin-Opener-Policy "same-origin" always; add header Cross-Origin-Resource-Policy "same-origin" always; add header Cross-Origin-Embedder-Policy "require-corp" always; 3.2 Content Security Policy CSP CSP is the most complex but most powerful header. It defines what sources of scripts, styles, images, etc. are allowed: csp directives: default src: purpose: "Fallback for other directives" typical: "'self'" script src: purpose: "Allowed JavaScript sources" common additions: - "'self'" - "https://www.googletagmanager.com" - "https://www.google-analytics.com" - "'unsafe-inline'" Often required; reduces protection avoid: "'unsafe-eval' unless absolutely required" style src: purpose: "Allowed CSS sources" common: "'self' 'unsafe-inline' https://fonts.googleapis.com" img src: purpose: "Allowed image sources" common: "'self' data: https:" font src: purpose: "Allowed font sources" common: "'self' https://fonts.gstatic.com" connect src: purpose: "Allowed fetch/XHR destinations" common: "'self' https://www.google-analytics.com" frame ancestors: purpose: "Who can iframe this page" typical: "'self'" note: "Replaces X-Frame-Options" base uri: purpose: "Restrict <base element" typical: "'self'" form action: purpose: "Where forms can submit" typical: "'self'" 3.3 CSP Implementation Approach csp implementation: step 1 audit: - Inventory all script sources - Inventory all style sources - Inventory all image, font, fetch sources step 2 report only: header: "Content-Security-Policy-Report-Only" purpose: "Test policy without enforcement" duration: "Run 1-2 weeks; collect violations" step 3 iterate: - Review violation reports - Adjust policy to allow legitimate sources - Block malicious or unnecessary step 4 enforce: header: "Content-Security-Policy" purpose: "Switch from report-only to enforcement" step 5 monitor: - Continued violation reporting via report-uri or report-to - Adjust as legitimate needs change 4. WordPress-Specific Security For Joseph's significant WordPress portfolio: 4.1 WordPress Hardening Baseline wordpress hardening: core updates: requirement: "WordPress core auto-updates enabled" cadence: "Weekly verification across portfolio" automation: "Automatic for security patches; managed for major versions" plugins: rule: "Only install reputable plugins from wordpress.org or trusted sources" audit: "Quarterly plugin audit per site" remove: "Inactive plugins security surface " update: "Auto-updates enabled for security; managed for major versions" themes: rule: "Reputable themes only" audit: "Inactive themes removed" custom themes: "Maintained and updated" user accounts: admin username: "Never 'admin' default " default role: "Subscriber for new users" role review: "Quarterly review of administrators" inactive users: "Removed periodically" password security: requirement: "Strong passwords enforced" plugin: "Force Strong Passwords or similar" two factor: "Enabled for administrators" file permissions: files: "644" directories: "755" wp config: "600" wp config hardening: keys: "Salts/keys regenerated; never default" db prefix: "Non-default 'wp ' is default; change to random " debug: "False in production" xml rpc: typical: "Disable unless required mobile app, Jetpack " method: ".htaccess block or plugin" rest api: public endpoints: "Restrict where appropriate" plugin: "Disable WP REST API or similar for restriction" login protection: rate limiting: "Limit Login Attempts plugin" captcha: "On login form" two factor: "Wordfence 2FA, Google Authenticator, etc." custom login url: "WPS Hide Login or similar" 4.2 WordPress Security Plugins wordpress security plugin options: wordfence: type: "Comprehensive security suite" features: "Firewall", "Malware scan", "Login protection", "2FA" cost: "Free + Premium" recommended for: "Most WordPress sites" sucuri: type: "Comprehensive security suite" features: "Firewall", "Malware scan", "Cleanup service" cost: "Free plugin + paid services" recommended for: "Sites needing managed cleanup" patchstack: type: "Vulnerability patching" features: "Virtual patching", "Vulnerability database" cost: "Paid" recommended for: "Sites with many plugins" ithemes security: type: "Comprehensive security suite" features: "Various hardening", "2FA", "Log monitoring" cost: "Free + Pro" recommended for: "Alternative to Wordfence" For Joseph's hosting situation managing 130+ sites: standardizing on one security solution simplifies management. Wordfence Premium across portfolio with central monitoring is common pattern. 4.3 WordPress Backup wordpress backup strategy: frequency: files: "Daily for high-change sites; weekly for static-content" database: "Daily minimum" retention: daily: "Keep 7-30 days" weekly: "Keep 4-12 weeks" monthly: "Keep 6-12 months" storage: requirement: "Off-server location" options: - S3 / Backblaze B2 / Wasabi - Other cloud storage - Different physical server avoid: "Backups only on same server lost in compromise " testing: quarterly: "Test restore procedure" purpose: "Verify backups are actually viable" plugins: options: - UpdraftPlus most popular - BackWPup - Duplicator Pro - WP Time Capsule server side: - rsync to off-server location - Scripted backup to S3 or similar 5. Server-Level Security For Joseph's self-managed Linux infrastructure: 5.1 SSH Hardening /etc/ssh/sshd config Disable root login PermitRootLogin no Use SSH keys only, no passwords PasswordAuthentication no ChallengeResponseAuthentication no Limit users who can SSH AllowUsers joseph backupuser Change default port security through obscurity, but reduces noise Port 22042 Or any non-standard port Limit authentication attempts MaxAuthTries 3 LoginGraceTime 30 Modern protocol only Protocol 2 Strong key exchange KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256 Modern ciphers only Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com After changes: sshd -t Test config systemctl restart sshd 5.2 Firewall UFW or iptables Basic UFW configuration ufw default deny incoming ufw default allow outgoing Allow SSH on custom port if changed ufw allow 22042/tcp Allow web traffic ufw allow 80/tcp ufw allow 443/tcp Enable firewall ufw enable Status ufw status verbose 5.3 Fail2ban Prevents brute force attacks: apt install fail2ban /etc/fail2ban/jail.local DEFAULT bantime = 3600 findtime = 600 maxretry = 3 sshd enabled = true port = 22042 nginx-http-auth enabled = true wordpress enabled = true filter = wordpress logpath = /var/log/nginx/access.log 5.4 Automatic Security Updates Debian/Ubuntu unattended-upgrades apt install unattended-upgrades dpkg-reconfigure -plow unattended-upgrades Configure /etc/apt/apt.conf.d/50unattended-upgrades Enable security updates Configure email notifications 5.5 Log Monitoring log monitoring: what to monitor: - Failed login attempts auth.log - Web server errors nginx error log - Suspicious request patterns nginx access log - Application errors varies tools: - logwatch daily summary email - GoAccess real-time web log analysis - Centralized logging ELK stack, Graylog, etc. for larger setups alerts: - Unusual login patterns - High error rates - Suspicious traffic patterns - Disk space warnings 6. Cloudflare WAF For sites where Joseph manages or recommends: cloudflare security layer: free tier features: - Free SSL/TLS - Basic DDoS protection - Bot fight mode - Browser integrity check pro tier additions: - WAF rules managed rulesets - Image optimization - Mobile redirect business tier additions: - Custom WAF rules - Rate limiting - Page rules with more options setup steps: - Add domain to Cloudflare - Update nameservers - Verify proxying enabled orange cloud - Configure SSL mode Full Strict recommended - Enable security features - Test thoroughly custom rules examples: block xmlrpc: "Block /xmlrpc.php to all WordPress " rate limit login: "Rate limit /wp-login.php" block known bad ips: "Block IPs from threat intelligence" challenge high risk countries: "Where business doesn't operate" 7. Application Security 7.1 Common Vulnerabilities OWASP Top 10 owasp top 10 2021: A01 broken access control: examples: "Path traversal, IDOR, missing authorization" prevention: "Server-side authorization checks; least privilege" A02 cryptographic failures: examples: "Weak encryption, plaintext passwords" prevention: "Modern crypto; password hashing bcrypt, argon2 " A03 injection: examples: "SQL injection, XSS, command injection" prevention: "Parameterized queries; input sanitization; output encoding" A04 insecure design: examples: "Missing security in design" prevention: "Threat modeling; secure design patterns" A05 security misconfiguration: examples: "Default credentials, verbose errors, missing headers" prevention: "Security baselines; configuration audits" A06 vulnerable components: examples: "Outdated libraries, dependencies" prevention: "Dependency scanning; regular updates" A07 authentication failures: examples: "Weak passwords, session management issues" prevention: "Strong auth, MFA, session security" A08 software data integrity failures: examples: "Unsigned updates, deserialization vulns" prevention: "Signed updates; safe deserialization" A09 logging monitoring failures: examples: "No logging, no monitoring" prevention: "Comprehensive logging; alerting" A10 ssrf: examples: "Server-side request forgery" prevention: "URL validation; allow lists" 7.2 Input Validation & Output Encoding php // PHP example — parameterized query prevents SQL injection $stmt = $pdo- prepare "SELECT FROM users WHERE email = ?" ; $stmt- execute $email ; // JavaScript — output encoding prevents XSS element.textContent = userInput; // Safe element.innerHTML = userInput; // DANGEROUS // React — automatic encoding {userInput} // Safe dangerouslySetInnerHTML={{ html: userInput}} // DANGEROUS 8. Incident Response 8.1 Incident Response Plan incident response phases: preparation: - Documented response plan - Contact list hosting, registrar, security firm - Backup access verified - Logging in place to support investigation detection: - Monitoring alerts - User reports - Security tools detection - Search engine warnings containment: immediate: - Take site offline if active attack - Change all credentials - Block attacker IP if identified short term: - Isolate affected systems - Preserve evidence - Engage security team or service if needed eradication: - Identify root cause - Remove malicious content - Patch vulnerability - Verify thorough cleanup recovery: - Restore from clean backup if needed - Bring systems back online - Verify normal operation - Monitor closely for return post incident: - Root cause analysis - Documentation - Process improvements - Affected user notification if applicable 8.2 Common Incidents common incident types: malware injection: detection: "Malware scan, GSC security warning" response: "Identify entry point; clean files; patch vulnerability" defacement: detection: "Visual inspection; user reports" response: "Restore from backup; identify entry point" data breach: detection: "Database access patterns; user reports" response: "Major incident; legal counsel; user notification" ddos: detection: "Traffic spike; service degradation" response: "Cloudflare or similar; rate limiting" account compromise: detection: "Unusual admin activity; user reports" response: "Lock account; force password reset; audit logs" 8.3 Manual Action from Hacked Content If GSC reports manual action for hacked content: - Address issue per Section 8.1 - Verify thorough cleanup - Submit reconsideration request via GSC - Document remediation work 9. Privacy and Compliance 9.1 Privacy Considerations privacy baseline: privacy policy: requirement: "Comprehensive policy on every site" contents: - Data collected - How used - Third parties - User rights - Contact information cookie consent: requirement: "EEA traffic; good practice elsewhere" implementation: "CMP per framework-ga4.md" user data handling: minimum collection: "Only collect what's needed" secure storage: "Encrypt at rest" secure transmission: "Always HTTPS" retention limits: "Don't keep indefinitely" deletion rights: "Process user deletion requests" 9.2 Regulatory Compliance relevant regulations: gdpr: "EU and UK; comprehensive privacy law" ccpa cpra: "California; consumer privacy" hipaa: "Healthcare data in US" pci dss: "Payment card data" ferpa: "Educational records" coppa: "Children under 13" For client sites, compliance is the client's legal responsibility but Joseph's implementation should support compliance HTTPS, consent, secure handling, etc. . 10. Audit Mode | | Criterion | Pass/Fail | |---|---|---| | SEC1 | HTTPS enforced sitewide | | | SEC2 | SSL Labs grade A or A+ | | | SEC3 | All security headers configured | | | SEC4 | CSP implemented at least basic | | | SEC5 | WordPress hardening baseline applied if WP | | | SEC6 | Security plugin active if WP | | | SEC7 | Backup strategy implemented and tested | | | SEC8 | SSH hardened key auth, no root | | | SEC9 | Firewall configured | | | SEC10 | Fail2ban or equivalent active | | | SEC11 | Automatic security updates enabled | | | SEC12 | Cloudflare or equivalent WAF where appropriate | | | SEC13 | Log monitoring established | | | SEC14 | Vulnerability scanning periodic | | | SEC15 | Incident response plan documented | | | SEC16 | Privacy policy current | Score: 16. World-class security baseline: 14+/16. 11. Common Mistakes - HTTP still allowed — must redirect or fail - Missing security headers — easy wins skipped - Default WordPress credentials — admin username, weak password - Outdated plugins/themes — primary WordPress attack vector - No backup off-server — backup destroyed in compromise - No vulnerability scanning — issues unknown until exploited - No 2FA — account compromise risk - Verbose error messages — leak information to attackers - Default ports and configurations — easier to attack - No incident response plan — paralysis when incident occurs End of Framework Document Companion documents: - framework-https.md — HTTPS implementation specifics overlap - framework-hosting.md — Hosting environment security - framework-spampolicies.md — Manual actions from hacked content - framework-wordpress.md — WordPress-specific implementation - framework-serverconfig.md — Server configuration About this framework library Dev.to republish of a framework from ThatDevPro's SEO + AI engineering library. Canonical source: https://www.thatdevpro.com/insights/framework-security/ ThatDevPro is an SDVOSB-certified veteran-owned web + AI engineering studio. Need this framework implemented? See the Engine Optimization service https://www.thatdevpro.com/services/engine-optimization/ or hire via contact https://www.thatdevpro.com/contact/ .