Https

Serve all pages over HTTPS

Plain HTTP exposes every request and response to anyone on the network path — ISPs, Wi-Fi operators, and MITM attackers can read passwords, session tokens, and personal data without any warning to the user.

Quick Reference

• All HTTP traffic must redirect to HTTPS with a 301 (permanent) redirect
• TLS certificates must be valid, not expired, and cover all hostnames (including www)
• HTTPS is a prerequisite for HSTS, HTTP/2, Service Workers, geolocation, and other modern APIs
• Use a free certificate from Let's Encrypt or your hosting provider's managed TLS
• Verify the certificate chain with SSL Labs (ssllabs.com/ssltest) — aim for A or A+

Check

Check whether all pages of this website are served over HTTPS. Verify the TLS certificate is valid, not expired, and covers all hostnames. Confirm HTTP requests redirect to HTTPS with a 301 status code.

Fix

Configure the web server to obtain a TLS certificate (e.g., via Let's Encrypt/Certbot), redirect all HTTP requests to HTTPS with a 301 redirect, and ensure all internal links and resources use HTTPS URLs.

Explain

Explain why serving pages over HTTPS is essential for security, what happens when plain HTTP is used, and how to obtain and configure a TLS certificate.

Code Review

Review server config, headers, forms, and integration points related to Serve all pages over HTTPS. Flag exact responses, cookies, or browser behaviors that violate the rule, and verify them against the effective production-like response.

---

For full implementation details, code examples, and framework-specific guidance, see references/rule.md.

Rule page: https://frontendchecklist.io/en/rules/security/https

Serve all pages over HTTPS

Every page and resource on your site must be delivered over HTTPS to protect user data in transit and enable modern browser features.

Priority: critical · Difficulty: beginner · Time: 30 min

--- HTTPS (HTTP over TLS) encrypts all traffic between the browser and your server, providing confidentiality, integrity, and authentication. MDN's transport security guidance and the OWASP transport cheat sheet both treat site-wide HTTPS as the baseline, not an optional hardening step.

Code Example

#

Let's Encrypt (Free)

# Install Certbot
sudo apt install certbot python3-certbot-nginx  # Debian/Ubuntu
sudo yum install certbot python3-certbot-nginx  # RHEL/CentOS

# Obtain and auto-configure certificate for Nginx
sudo certbot --nginx -d example.com -d www.example.com

# Certbot automatically sets up renewal
# Test renewal with:
sudo certbot renew --dry-run

Hosted / Managed TLS

Most platforms handle TLS automatically:

• Vercel: Automatic — certificates provisioned for all deployments
• Netlify: Automatic — one-click HTTPS via Let's Encrypt
• AWS CloudFront: Use AWS Certificate Manager (free for CloudFront)
• Cloudflare: Managed TLS included on all plans

Why It Matters

Plain HTTP exposes every request and response to anyone on the network path — ISPs, Wi-Fi operators, and MITM attackers can read passwords, session tokens, and personal data without any warning to the user.

What HTTPS Provides

• Confidentiality: Data cannot be read by third parties on the network path
• Integrity: Data cannot be modified in transit (prevents content injection by ISPs or MITM attackers)
• Authentication: The certificate proves the server is who it claims to be, preventing impersonation

HTTP-to-HTTPS Redirect

Nginx

# Redirect all HTTP to HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # ...
}

Apache

    ServerName example.com
    Redirect permanent / https://example.com/

Cloudflare

In the Cloudflare dashboard → SSL/TLS → Edge Certificates → enable Always Use HTTPS and set Minimum TLS Version to 1.2.

Modern Features Requiring HTTPS

Both MDN and web.dev treat these as secure-context features, so they are a practical way to spot pages that still rely on insecure origins.

Browsers block these APIs on non-secure origins:

If your HTTPS page loads any resource over HTTP, the page is considered mixed content. Active mixed content such as scripts and iframes is blocked outright, so audit resource URLs and ensure they use HTTPS.

Common Pitfalls

Exceptions

• Local development or internal-only environments can differ, but production user-facing traffic should still satisfy the transport requirement strictly.
• A redirect or HTTPS control that fails on one hostname, subdomain, or CDN edge path is still a real failure for users and crawlers reaching that surface.
• Fix the strongest transport weakness first instead of treating every downstream symptom as a separate primary issue.

Support Notes

• Verify HTTPS behavior in a production-like environment with the real certificate chain, redirects, proxies, and CDN path in place.
• Modern secure-context features may appear to work locally while still failing or degrading on real production hosts.

Verification

Automated Checks

• Run an automated security check, scripted probe, or log-based validation against a representative live flow.

Manual Checks

• Verify the browser or user-facing behavior manually in a production-like flow and confirm there is no stronger conflicting security signal.