Cloudflare Command Center: Domains, DNS, Zero Trust, and Tunnels from Beginner to Expert Part 6: Free Security Wins. SSL, HTTPS, DNSSEC, DDoS Protection, and Basic Hardening

Part 5 built the foundation. You walked through DNS record types, understood how Cloudflare's proxy works at the network level, and got your domain pointed correctly. That's the structural work. It's necessary, and it's done. Now the question shifts from "is my DNS configured?" to "is my site actually secure?"

The answer, for most sites running without Cloudflare, is probably not as much as you'd think.

Security features that used to require a paid CDN contract, a dedicated security appliance, or a managed hosting tier are sitting in your Cloudflare free account right now, waiting to be turned on. Most of them take under five minutes to enable. Most site owners never touch them. That gap between what's available and what's actually configured is exactly where this part lives.

What Cloudflare Gives You for Free (And Why It Matters)

The Security Gap Most Site Owners Don't Know They Have

When you sign up for shared hosting, you get a server. Maybe you get a free SSL certificate through Let's Encrypt if the host has configured it. What you almost certainly don't get is DDoS mitigation, DNS spoofing protection, automatic HTTPS enforcement, or a security dashboard that tells you what's hitting your site. Those things cost money elsewhere. Real money.

The average shared hosting plan gives you file storage and PHP execution. Security is your problem. That's not a criticism of hosting providers. It's just the reality of what the product is.

Cloudflare sits in front of your server and handles threats before they arrive. That positioning matters. A firewall on your server still receives the traffic. Cloudflare can drop it at the edge, miles upstream from your origin.

How Cloudflare's Free Tier Compares to Paid Alternatives

Dedicated DDoS mitigation services have historically charged hundreds of dollars per month for the kind of volumetric attack protection Cloudflare includes at no cost. Web application firewalls from vendors like Imperva or Akamai carry enterprise price tags. A managed SSL certificate with auto-renewal from a traditional CA costs anywhere from $10 to several hundred dollars annually depending on the certificate type.

This part covers five specific areas: SSL certificate provisioning, HTTPS enforcement, DNSSEC, DDoS protection, and the security dashboard. Each one addresses a real attack surface. None of them require a credit card.

Enabling these features takes minutes. Understanding what they actually do takes a bit longer, which is why this part exists.

Universal SSL: Free HTTPS for Every Domain on Cloudflare

How Universal SSL Works Under the Hood

When you proxy a domain through Cloudflare, the platform provisions an SSL certificate for it automatically. No manual CSR generation. No certificate authority verification emails. No waiting days for approval. Within minutes of your DNS going active through Cloudflare's proxy, Universal SSL kicks in and your domain is reachable over HTTPS.

What's actually happening involves two separate encryption legs. The first is the edge certificate: the connection between a visitor's browser and Cloudflare's network. That's what Universal SSL covers. The second is the origin certificate: the connection between Cloudflare and your actual server. Universal SSL does not automatically secure that leg. That's handled by your SSL mode setting, which the next section covers in full.

Shared Certificates vs. Dedicated Certificates

Universal SSL uses a shared SAN certificate. SAN stands for Subject Alternative Name. Cloudflare groups multiple domains onto a single certificate and lists each one as an alternative name. Your domain shares a certificate with other Cloudflare customers.

In practice, this is fine for most use cases. Browsers validate the certificate correctly, the padlock appears, and traffic is encrypted. The only scenario where this becomes relevant is if you have compliance requirements specifying a dedicated certificate, or if you're in an industry where sharing certificate infrastructure with unknown third parties raises flags. For everyone else, it works exactly as expected.

Dedicated certificates are available on paid plans. They issue a certificate exclusively for your domain, which also unlocks wildcard subdomain coverage.

Checking Your SSL Certificate Status in the Dashboard

Navigate to your domain in the Cloudflare dashboard, then go to SSL/TLS > Overview. The certificate status appears near the top of the page. You're looking for "Active Certificate" with a green indicator.

If provisioning fails, the most common cause is a DNS misconfiguration. Cloudflare needs the domain to be proxied (orange cloud) rather than DNS-only (grey cloud) for Universal SSL to work. Occasionally, a newly added domain takes up to 24 hours to provision if the certificate authority queue is backed up, though most provisioning completes in under 15 minutes.

Auto-renewal is fully managed by Cloudflare. You don't set calendar reminders. You don't run certbot. The certificate renews before expiration without any action on your part.

SSL Modes Explained: Choosing Between Flexible, Full, and Full (Strict)

Flexible SSL: The Most Dangerous 'Easy' Option

Flexible SSL is the default for many newly connected domains. It's also the mode most likely to give you a false sense of security. Here's what it actually does: the connection between your visitor's browser and Cloudflare is encrypted. The connection between Cloudflare and your origin server is not. That second leg travels in plaintext.

Your visitors see a padlock. The data is unencrypted between Cloudflare and your server. If someone can intercept traffic at the hosting infrastructure level, Flexible SSL offers no protection for that leg of the journey. It's not a theoretical concern. It's a real gap.

There's a second problem. If your origin server already has SSL configured, enabling Flexible SSL often causes a redirect loop. Your server tries to redirect HTTP to HTTPS. Cloudflare sends an HTTP request to the origin. The origin redirects to HTTPS. Cloudflare sends another HTTP request. The loop never resolves and visitors get a browser error.

Full SSL: Better, But Still Has a Flaw

Full SSL encrypts both legs of the connection. The browser-to-Cloudflare leg uses the edge certificate. The Cloudflare-to-origin leg is also encrypted. The flaw is that Cloudflare doesn't validate your origin certificate in Full mode. It will accept a self-signed certificate, an expired certificate, or a certificate issued for the wrong domain.

This creates a man-in-the-middle risk on the origin leg. An attacker who could intercept traffic between Cloudflare and your origin could present any certificate and Full mode would accept it without complaint.

Full (Strict): The Right Choice for Most Sites

Full (Strict) encrypts both legs and validates the origin certificate. Cloudflare checks that the certificate is valid, unexpired, and issued for the correct domain. This is the mode you should be using.

The requirement is that your origin server must have a valid SSL certificate. If your host provides one through Let's Encrypt, that works. If you want to issue one through Cloudflare itself, the Origin CA certificate in the Cloudflare dashboard is free and designed specifically for this purpose. It's only trusted by Cloudflare, not by browsers directly, but that's fine because browsers never connect to your origin directly when Cloudflare is proxying.

Off Mode: When and Why You Would Ever Use It

Off mode disables SSL entirely. HTTP only. There is almost no scenario in which a production site should use this. The one legitimate use case is troubleshooting a provisioning failure where you need to confirm the origin is reachable before layering encryption back in. Enable it temporarily, confirm what you need to confirm, and turn it back off immediately.

Always Use HTTPS and Automatic HTTPS Rewrites

Always Use HTTPS: Forcing Secure Connections at the Edge

Always Use HTTPS is a single toggle in the Cloudflare dashboard under SSL/TLS > Edge Certificates. When enabled, any HTTP request that arrives at Cloudflare's edge receives a 301 redirect to the HTTPS version of the same URL. The redirect happens at Cloudflare's network before the request ever reaches your server.

This is distinct from HSTS, which is an HTTP response header that tells browsers to only request HTTPS versions of your site in the future, storing that preference locally. Always Use HTTPS handles the redirect at the network level. HSTS tells the browser to not even attempt HTTP in the first place. They solve related but different problems, and enabling one doesn't replace the other. The HSTS setting is also available on the same Edge Certificates page if you want to layer both.

Automatic HTTPS Rewrites: Fixing Mixed Content Without Touching Code

Mixed content happens when an HTTPS page loads resources over HTTP. An image tag with an http:// source. A stylesheet pulled from an insecure URL. A script loaded without the S. Browsers flag this. Some browsers block it. All browsers show a warning that undermines visitor trust.

Automatic HTTPS Rewrites addresses this by rewriting HTTP resource URLs to HTTPS in HTML responses as they pass through Cloudflare's edge. A page that references http://yourdomain.com/image.jpg gets that URL rewritten to https://yourdomain.com/image.jpg before the browser ever sees it. No code changes. No database updates. No plugin required.

The Difference Between These Two Settings and Why You Need Both

Always Use HTTPS handles the page request itself. Automatic HTTPS Rewrites handles the resources embedded within the page. They operate on different parts of the same problem. A site with Always Use HTTPS but without Automatic HTTPS Rewrites will serve the page over HTTPS but may still have mixed content warnings from embedded resources. A site with Automatic HTTPS Rewrites but without Always Use HTTPS can still be accessed over HTTP directly.

Enable both. They're toggles on the same dashboard page. The one limit to know: Automatic HTTPS Rewrites cannot help with external third-party resources hosted on domains that don't support HTTPS at all. If a plugin loads a script from a third-party server that only serves HTTP, Cloudflare can rewrite the URL but the request will fail if the remote server doesn't respond on HTTPS. That situation requires updating the source or replacing the third-party resource.

Fixing Mixed Content: A Practical Walkthrough

How to Identify Mixed Content Using Browser DevTools

Open Chrome and navigate to the page showing the mixed content warning. The padlock in the address bar will show a warning indicator rather than a clean lock. Open DevTools with F12 or right-click and inspect. The Console tab will list mixed content errors directly, showing the exact URL of each insecure resource. The Security tab provides a summary view that categorizes what's secure and what isn't.

Write down the URLs. They tell you where the problem lives.

Common Sources of Mixed Content and How to Resolve Each

The most common culprits follow a predictable pattern. Hardcoded HTTP image URLs in CMS content fields. Theme assets referenced with absolute HTTP paths instead of relative paths or HTTPS. Plugin-loaded scripts that pull resources from external servers using HTTP.

There's an important distinction between passive mixed content and active mixed content. Passive content is things like images and video. Browsers display a warning but still load the resource. Active content is scripts and stylesheets. Browsers block active mixed content entirely, which can break page functionality.

In WordPress, the most common fix involves two steps. First, update the site URL settings under Settings > General so both the WordPress Address and Site Address use HTTPS. Second, run a search-replace on the database to update any hardcoded HTTP URLs stored in post content. The Better Search Replace plugin handles this without requiring command-line access. Search for http://yourdomain.com, replace with https://yourdomain.com, and run it across all tables.

When You Need to Fix the Code Versus Let Cloudflare Handle It

Automatic HTTPS Rewrites handles most mixed content from your own domain automatically. If the insecure resource is hosted on your domain and the server supports HTTPS, the rewrite works. If the resource is an external third-party asset from a domain that doesn't support HTTPS, no rewrite will save it. You need to either update the source to a version that serves HTTPS or remove the resource entirely. Cloudflare can only rewrite URLs it can verify will work over HTTPS.

DNSSEC: Protecting Your Domain from DNS Spoofing

What DNSSEC Does and Why DNS Is Vulnerable Without It

DNS is, by design, unauthenticated. When a resolver asks for the IP address of your domain, the response it receives has no built-in way to prove it came from an authoritative source. DNS cache poisoning exploits this. An attacker floods a resolver with forged responses, hoping to replace the legitimate IP address with one they control. If they succeed, visitors typing your domain into a browser get sent to a fake server without any warning.

DNSSEC adds cryptographic signatures to DNS records. When a resolver receives a DNS response with DNSSEC enabled, it can verify the signature against a chain of trust anchored at the DNS root. A forged response fails verification and gets discarded.

DNSSEC doesn't hide anything. It proves that the answer you received is the one the zone owner actually published.

Basic DDoS Protection: What Cloudflare Does Automatically

Part 5 got your SSL certificates issued and your DNSSEC wired up. Now the question shifts from "is my traffic encrypted" to "can my site stay standing when someone decides to ruin your afternoon." That's where DDoS protection enters the picture, and the free plan gives you more here than most people realize.

How Cloudflare's Network Absorbs Attack Traffic

Cloudflare operates one of the largest anycast networks on the planet. When traffic arrives destined for your domain, it doesn't hit your server first. It hits the nearest Cloudflare data center, of which there are hundreds spread across every major region. That geographic distribution is the core of the protection.

When a volumetric attack fires, the traffic gets absorbed and scrubbed at the edge. Your origin server never sees the flood. It sees normal, filtered requests, or nothing at all during an active mitigation event. That's the fundamental architecture, and it applies to every plan, including free.

Layer 3/4 vs. Layer 7 DDoS: What the Free Plan Covers

Layer 3 and Layer 4 attacks target the network and transport layers. Think UDP floods, SYN floods, and ICMP amplification. These are the volumetric attacks designed to saturate bandwidth or exhaust connection tables. Cloudflare's anycast network handles these automatically, with no configuration required and no traffic cap on how much it will absorb.

Layer 7 attacks are more surgical. They look like legitimate HTTP requests but arrive in volumes designed to exhaust your application. Free plan users get Cloudflare's HTTP DDoS managed rulesets running by default. These rulesets analyze traffic patterns, request rates, and behavioral signals to detect and challenge suspicious activity without you touching a single setting.

Sensitivity levels within the managed ruleset range from low to high. Cloudflare tunes these automatically based on observed traffic. Advanced overrides, custom thresholds, and rule-level adjustments are paid features, but the default behavior is genuinely solid for most small sites.

Reading DDoS Events in the Security Dashboard

When an attack event occurs, the record lives in Security > Events. Filter by action type, time range, or rule ID to see what the managed ruleset flagged. You won't always know an attack happened unless you look, which is a good argument for checking this log regularly.

One critical point: all of this protection assumes your origin IP is hidden. If an attacker knows your real server address, they can bypass Cloudflare entirely and hit the origin directly. Keep your IP private. Don't publish it in DNS records, email headers, or anywhere else it doesn't need to be.

The Security Dashboard: Your Free Command Center

The Security tab in the Cloudflare dashboard is underused by most free plan users. It contains more signal than people expect, and spending ten minutes a week in there is one of the highest-return habits you can build around your domain.

Navigating the Security Overview and Events Log

The Security tab breaks into several sub-sections. Overview gives you a summary of recent activity. Events is where the detailed log lives. Bots surfaces bot-specific traffic data. API Shield and WAF sections exist but unlock more functionality on paid plans.

The Events log is the most immediately useful tool. Every request that Cloudflare challenged, blocked, or flagged appears here with its associated rule, action, source IP, country, user agent, and timestamp. You can filter by action type, which means you can isolate everything that was blocked and ask whether those blocks look legitimate or whether something is being caught incorrectly.

Understanding Threat Score and Bot Traffic Indicators

Cloudflare assigns every visitor a threat score between 0 and 100. Zero means no detected risk. Higher scores indicate signals like known bad IP reputation, datacenter origin, or behavioral anomalies. Your Security Level setting determines what score threshold triggers a challenge. At Medium, visitors scoring above 14 get a challenge. That's the default recommendation for most sites.

Bot Fight Mode is a free toggle under Security > Bots. Enable it. When active, it detects and challenges requests from known bot operators. It won't stop every automated request, but it meaningfully reduces low-effort scraping and credential stuffing attempts.

Using Security Analytics to Spot Patterns

Security Analytics shows aggregate breakdowns of where your suspicious traffic originates, which user agents appear most frequently, and which countries are generating the most flagged requests.

If one country consistently generates 80 percent of your challenge events and you have no legitimate audience there, that's actionable information. You can create a firewall rule to challenge or block that traffic. The data is there. You just have to look at it.

Additional Free Hardening: Quick Wins Beyond the Defaults

The SSL settings and DDoS protections covered earlier are the foundation. These settings are the next layer, and most of them take under two minutes to configure.

HSTS: Adding Strict Transport Security Headers

HSTS (HTTP Strict Transport Security) tells browsers that your domain should only ever be accessed over HTTPS. Once a browser receives the header, it refuses to make plain HTTP connections to your domain for the duration of the max-age period. Cloudflare lets you enable this under SSL/TLS > Edge Certificates.

For most sites, enabling HSTS with a six-month max-age and no preload is the right call. It adds meaningful protection against protocol downgrade attacks without creating an irreversible commitment.

Minimum TLS Version: Dropping Outdated Protocol Support

TLS 1.0 and TLS 1.1 are deprecated. They have known vulnerabilities, they're no longer supported by current PCI DSS standards, and there's no good reason to accept connections using them.

Set your minimum TLS version to 1.2 under SSL/TLS > Edge Certificates. The setting takes effect immediately at the edge. Any client attempting a TLS 1.0 or 1.1 handshake gets rejected. The realistic population of users still running browsers that can't handle TLS 1.2 is essentially zero at this point.

TLS 1.3 is worth enabling separately. It reduces handshake latency, removes several legacy cipher suites, and improves forward secrecy. Enable it in the same section. It operates alongside TLS 1.2 rather than replacing it, so clients that support 1.3 get the faster, more secure connection automatically.

Opportunistic Encryption and TLS 1.3

Opportunistic Encryption is a lesser-known setting that encrypts traffic even for requests made over HTTP, using TLS without requiring a redirect. It doesn't change the URL or the user experience. It just encrypts the transport layer for visitors who arrive via HTTP before any redirect fires. Enable it. There's no downside.

The combination of minimum TLS 1.2, TLS 1.3 enabled, HSTS active, and Opportunistic Encryption on means your transport layer is genuinely solid, at no cost and with about five minutes of configuration.

Common SSL and Security Mistakes (And How to Avoid Them)

The settings are straightforward. The mistakes are predictable. These are the ones that show up most often.

The Redirect Loop Trap

Flexible SSL is the source of more redirect loops than any other Cloudflare misconfiguration. Here's what happens: Cloudflare connects to your origin over plain HTTP because Flexible doesn't require an origin certificate. Your origin, running a WordPress install or a hosting panel, has HTTP-to-HTTPS redirects enabled. Cloudflare receives the redirect, follows it, gets another redirect, and the loop runs until the browser gives up with an ERR_TOO_MANY_REDIRECTS error.

Diagnose a redirect loop with curl -I --max-redirs 5 http://yourdomain.com and watch the Location headers. If you see the same URL bouncing back and forth, Flexible SSL is almost certainly the cause.

Exposing Your Origin IP

Cloudflare's protection only works if traffic actually flows through Cloudflare. If your origin IP is publicly known, attackers can route around the proxy entirely.

Check every DNS record in your Cloudflare dashboard. Any A or AAAA record pointing to your origin should have the proxy enabled unless there's a specific technical reason it can't be.

Setting It and Forgetting It

Two things break silently over time. First, DNSSEC requires re-validation if you migrate registrars or change nameservers. The DS record at your registrar must match what Cloudflare is signing. A mismatch causes DNSSEC validation failures that look like outages to DNSSEC-validating resolvers.

Second, origin certificates expire. Cloudflare's edge certificate auto-renews, but if you're running Full (Strict) mode and your origin certificate lapses, Cloudflare can't validate the connection and your site goes down. Set a calendar reminder for 30 days before your origin certificate expires and treat it as a hard deadline.

Your Free Security Checklist: What to Enable Right Now

Everything covered in this part distills into a single checklist. Work through it once when you set up a new domain. Revisit it quarterly.

That's the full security layer for a free Cloudflare account. No paid plan required for any of it. Part 7 shifts from protection to performance, covering Cloudflare's caching system, cache rules, cache-control headers, and how to configure page rules and cache levels to actually speed up your site instead of accidentally serving stale content to everyone.