CDN Endpoint Allows Plain HTTP: Why It Matters and How to Fix It

Content delivery networks sit at the edge of your application, often serving the very first bytes a user sees. When a CDN endpoint accepts unencrypted HTTP, you hand attackers a foothold on the most exposed part of your stack. The cdn_httpenabled check looks at your Azure CDN endpoints and raises a finding whenever one still permits plain HTTP connections.

This is a small misconfiguration with an outsized blast radius. Below we cover what the check detects, why HTTP on a CDN is risky, and exactly how to lock it down across the portal, CLI, and infrastructure as code.

---

What this check detects

Azure CDN endpoints expose two protocol toggles: isHttpAllowed and isHttpsAllowed. By default, both are enabled when you create an endpoint. The cdn_httpenabled check inspects each endpoint in your subscription and flags any where isHttpAllowed is set to true.

An endpoint in this state will happily complete a request on port 80 without TLS. The content, the URL path, query strings, cookies, and any headers travel across the network in the clear.

---

Why it matters

Allowing HTTP is not just a compliance checkbox failure. It opens a few concrete attack paths.

Traffic interception

Anyone positioned between the user and the edge node, a malicious Wi-Fi access point, a compromised router, or an ISP-level attacker, can read everything sent over HTTP. For static sites that feels low-risk, but CDNs frequently serve JavaScript, configuration files, and session-bearing assets. Reading those in transit is the first step toward something worse.

Content injection

HTTP responses can be modified mid-flight. An attacker who can intercept the connection can inject malicious JavaScript into a script you serve, rewrite a download link, or replace an image with a phishing prompt. The user's browser trusts it because it came from your domain.

Protocol downgrade and SSL stripping

Even if most of your users hit HTTPS, an endpoint that accepts HTTP enables SSL stripping. The attacker intercepts the initial plaintext request and quietly keeps the victim on HTTP while talking HTTPS to your origin. The user never sees the lock icon disappear if they were not watching for it.

SEO and browser penalties

Modern browsers mark HTTP pages as "Not Secure," and search engines downgrade them in rankings. Beyond security, leaving HTTP open costs you trust and visibility.

---

How to fix it

The goal is twofold: disable HTTP on the endpoint and add a redirect so existing HTTP clients are bounced to HTTPS rather than silently failing.

Option 1: Azure CLI

First, find the offending endpoints. This lists every CDN endpoint where HTTP is allowed:

az cdn endpoint list \
  --resource-group myResourceGroup \
  --profile-name myCdnProfile \
  --query "[?isHttpAllowed].{name:name, http:isHttpAllowed, https:isHttpsAllowed}" \
  --output table

Disable HTTP on a specific endpoint while keeping HTTPS on:

az cdn endpoint update \
  --resource-group myResourceGroup \
  --profile-name myCdnProfile \
  --name myEndpoint \
  --no-http true \
  --no-https false

Add an HTTP-to-HTTPS redirect rule

A redirect keeps old links working while forcing encryption. Create a rule on the endpoint that catches HTTP requests and returns a 301 to the HTTPS equivalent:

az cdn endpoint rule add \
  --resource-group myResourceGroup \
  --profile-name myCdnProfile \
  --name myEndpoint \
  --order 1 \
  --rule-name "redirectToHttps" \
  --match-variable RequestScheme \
  --operator Equal \
  --match-values HTTP \
  --action-name UrlRedirect \
  --redirect-protocol Https \
  --redirect-type Moved

With the redirect in place, you can safely keep HTTP enabled purely for redirection, or disable it after confirming clients have migrated.

Option 2: Azure Portal

1. Open your CDN profile and select the endpoint.
2. Under Settings, go to Origins or the endpoint overview to find the protocol toggles.
3. Uncheck HTTP so only HTTPS remains selected, then save.
4. Go to Rules engine, add a new rule, set the condition Request protocol equals HTTP, and the action URL redirect to HTTPS with a 301 response.

Option 3: Terraform

If you manage CDN endpoints as code, set the protocol flags explicitly and define a delivery rule for the redirect:

resource "azurerm_cdn_endpoint" "example" {
  name                = "my-endpoint"
  profile_name        = azurerm_cdn_profile.example.name
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name

  is_http_allowed  = false
  is_https_allowed = true

  origin {
    name      = "origin1"
    host_name = "www.example.com"
  }

  delivery_rule {
    name  = "redirectToHttps"
    order = 1

    request_scheme_condition {
      operator     = "Equal"
      match_values = ["HTTP"]
    }

    url_redirect_action {
      redirect_type = "Found"
      protocol      = "Https"
    }
  }
}

---

How to prevent it from happening again

Fixing one endpoint is easy. Stopping the next insecure one from being created is where the real value is.

Azure Policy

Azure Policy can audit or outright deny endpoints that allow HTTP. Assign a custom policy with this rule fragment:

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Cdn/profiles/endpoints"
      },
      {
        "field": "Microsoft.Cdn/profiles/endpoints/isHttpAllowed",
        "equals": true
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

Start with "effect": "audit" to measure how many existing endpoints would fail, then switch to deny once you have remediated them.

CI/CD gates

If you use Terraform, run a static check in your pipeline before apply. A simple Conftest policy in Rego catches the misconfiguration at PR time:

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "azurerm_cdn_endpoint"
  resource.change.after.is_http_allowed == true
  msg := sprintf("CDN endpoint '%s' allows HTTP", [resource.address])
}

Wire this into your plan stage so an insecure endpoint never reaches the apply step.

Continuous monitoring

Drift happens. Someone re-enables HTTP during a debugging session and forgets to revert it. A platform like Lensix re-runs the cdn_httpenabled check on a schedule and surfaces the regression before it lingers, so you are not relying on a once-a-quarter audit to catch it.

---

Best practices

• HTTPS only, always. Treat HTTP as legacy and only keep port 80 open to serve redirects, never to serve content.
• Use 301 redirects, not 302. A permanent redirect tells browsers and search engines to remember the HTTPS version and skip the HTTP round trip next time.
• Enable HSTS at the origin. Add a Strict-Transport-Security header so browsers refuse HTTP for your domain entirely, closing the SSL stripping window after the first visit.
• Use a modern minimum TLS version. Disabling HTTP is step one. Make sure HTTPS itself rejects TLS 1.0 and 1.1.
• Consider Azure Front Door for new workloads. It offers built-in HTTPS enforcement, WAF integration, and managed certificates, which removes several manual steps.
• Inventory every endpoint. Misconfigurations hide in the endpoints nobody remembers creating. Keep a running list and check it against your policy regularly.

Disabling plain HTTP on a CDN endpoint takes one command and a redirect rule, but it removes an entire class of interception and injection attacks from your edge. Fix the ones you have, gate the ones you might create, and let continuous checks catch the rest.