Drop www: Security Implications

TL;DR

Dropping ‘www’ (using example.com instead of www.example.com) isn’t a major cyber security risk in itself, but it can create issues with cookies, caching and consistent certificate coverage. It requires careful planning and configuration to avoid problems.

Understanding the Issue

Historically, ‘www’ was used as a subdomain indicating a web server. Now, many sites work perfectly well without it. Removing it simplifies things but introduces potential complications.

Steps to Securely Drop www

1. Choose Your Preferred Domain: Decide whether you want example.com or www.example.com as your primary domain. This is the most important step!
2. Redirects are Key: Implement a permanent (301) redirect from the non-preferred version to the preferred one. This tells search engines and browsers which site you want them to use.
   • Apache Example (.htaccess):

     RewriteEngine On
     RewriteCond %{HTTP_HOST} ^www.example.com [NC]
     RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]

   • NGINX Example (nginx.conf):

     server {
       listen 80;
       server_name www.example.com;
       return 301 https://example.com$request_uri;
     }
     

3. DNS Configuration: Ensure your DNS records point correctly.
   • If using example.com as primary, you need an ‘A’ record for example.com pointing to your server’s IP address. You may *not* need an A record for www.example.com (the redirect handles this).
   • If using www.example.com as primary, you need an 'A' record for both example.com and www.example.com pointing to your server’s IP address.
4. SSL Certificate Coverage: This is where cyber security concerns arise.
   • Your SSL certificate *must* cover both domains (example.com and www.example.com) or use a wildcard certificate (e.g., *.example.com).
   • If your certificate only covers one domain, users accessing the other will see browser warnings about an insecure connection. Let's Encrypt is a free option for obtaining certificates.

     certbot --nginx -d example.com -d www.example.com

5. Cookie Domain: Ensure your application sets cookies with the correct domain.
   • If you’re using example.com as primary, set cookie domains to example.com.
   • Using a subdomain (like www.example.com) for cookies when your main site is at example.com can cause issues with cross-subdomain access and security vulnerabilities.
6. Caching: Clear any caches (browser, server-side, CDN) after making changes to ensure the redirect works correctly.
7. Testing: Thoroughly test the redirection from both example.com and www.example.com using multiple browsers and devices. Check for SSL certificate errors.