Front Door Does Not Enforce HTTPS: Fixing the frontdoor_nohttps Check

Azure Front Door sits at the edge of your application, terminating connections from clients all over the world before forwarding requests to your backends. If a Front Door route still answers on HTTP, you have a public entry point where credentials, session tokens, and API payloads travel as cleartext over the open internet. This check, frontdoor_nohttps, looks for Front Door configurations that do not enforce HTTPS-only access and flags them so you can close that gap.

---

What this check detects

The check inspects your Azure Front Door routing rules and frontend endpoints to determine whether HTTP requests are forced to HTTPS. It fails when:

• A routing rule accepts the Http protocol and serves content without redirecting to HTTPS.
• No HTTP to HTTPS redirect rule exists to catch plain HTTP requests.
• A frontend endpoint allows unencrypted connections to pass through to a backend pool.

Both Front Door tiers are in scope. The classic Azure Front Door (classic) service uses routing rules with accepted protocols, while Azure Front Door Standard/Premium uses routes with a httpsRedirect setting. The underlying risk is the same: any route that answers HTTP without redirecting is a finding.

---

Why it matters

When a route accepts HTTP, everything a client sends before any redirect can occur is visible to anyone on the network path. That includes corporate proxies, public Wi-Fi access points, ISPs, and any attacker positioned to run a man-in-the-middle.

The concrete failure modes are worth spelling out:

• Credential and token theft. A login form posted over HTTP exposes the username and password in plaintext. An API request over HTTP exposes bearer tokens and API keys.
• Session hijacking. Cookies sent without the Secure flag over an HTTP request can be captured and replayed to impersonate the user.
• Content injection. An attacker on the path can rewrite the HTML or JavaScript in an HTTP response, injecting malicious scripts or redirecting users to a phishing page.
• SSL stripping. Even if you have a redirect, attackers can intercept the initial HTTP request and prevent the upgrade, keeping the victim on a downgraded connection.

There is also a compliance angle. PCI DSS, HIPAA, SOC 2, and most internal security baselines require encryption of data in transit. A Front Door endpoint serving HTTP is a straightforward audit finding that auditors will catch and ask you to remediate.

---

How to fix it

The fix is to force HTTP traffic to HTTPS. The exact steps depend on which Front Door tier you run.

Azure Portal (Standard/Premium)

1. Open your Front Door profile in the Azure Portal.
2. Go to Front Door manager and select the endpoint, then the route you want to change.
3. Under Accepted protocols, select HTTP and HTTPS.
4. Enable Redirect all traffic to use HTTPS.
5. Save the route. Repeat for every route on every endpoint.

Azure CLI (Standard/Premium)

Update the route to redirect HTTP to HTTPS:

az afd route update \
  --resource-group myResourceGroup \
  --profile-name myFrontDoorProfile \
  --endpoint-name myEndpoint \
  --route-name myRoute \
  --https-redirect Enabled \
  --supported-protocols Http Https \
  --forwarding-protocol HttpsOnly

The --forwarding-protocol HttpsOnly flag also forces the edge-to-origin leg onto HTTPS, which closes the gap behind the redirect.

Azure CLI (classic)

For classic Front Door, add or update a routing rule so it redirects HTTP to HTTPS:

az network front-door routing-rule update \
  --resource-group myResourceGroup \
  --front-door-name myClassicFrontDoor \
  --name httpToHttpsRedirect \
  --accepted-protocols Http \
  --route-type Redirect \
  --redirect-protocol HttpsOnly \
  --redirect-type Moved

Terraform (Standard/Premium)

resource "azurerm_cdn_frontdoor_route" "main" {
  name                          = "myRoute"
  cdn_frontdoor_endpoint_id     = azurerm_cdn_frontdoor_endpoint.main.id
  cdn_frontdoor_origin_group_id = azurerm_cdn_frontdoor_origin_group.main.id
  cdn_frontdoor_origin_ids      = [azurerm_cdn_frontdoor_origin.main.id]

  supported_protocols    = ["Http", "Https"]
  patterns_to_match      = ["/*"]
  forwarding_protocol    = "HttpsOnly"
  https_redirect_enabled = true
  link_to_default_domain = true
}

---

How to prevent it from happening again

Manual fixes drift. The durable solution is to enforce HTTPS as a default at the point where infrastructure is defined and to block non-compliant configurations before they reach production.

Azure Policy

Use Azure Policy to audit or deny Front Door routes that do not enforce HTTPS. A custom policy targeting the route resource type can check the httpsRedirect property:

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Cdn/profiles/afdEndpoints/routes"
      },
      {
        "field": "Microsoft.Cdn/profiles/afdEndpoints/routes/httpsRedirect",
        "notEquals": "Enabled"
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

Assign it at the subscription or management group scope. With the deny effect, any deployment that tries to create a route without HTTPS redirect is rejected outright.

CI/CD gates

Catch the problem in pull requests before it ever deploys. If you use Terraform, run a policy check on the plan with a tool like checkov or tfsec:

# Scan Terraform for insecure Front Door config
checkov -d ./infra --framework terraform \
  --check CKV_AZURE_121

Wire that into your pipeline so a failing check blocks the merge. Combine it with the Lensix frontdoor_nohttps check running against your live environment to catch anything created outside of IaC, such as manual portal changes or legacy resources.

---

Best practices

Enforcing the redirect is the baseline. To get the full security posture you want around Front Door, layer in these practices:

• Force HTTPS end to end. Set forwardingProtocol to HttpsOnly so the edge-to-origin hop is encrypted too, not just the client-to-edge hop.
• Send HSTS headers. Add a Strict-Transport-Security response header via a Front Door rules engine rule so browsers remember to use HTTPS and resist SSL stripping. Start with a short max-age, then raise it once you are confident.
• Set a minimum TLS version. Require TLS 1.2 or higher on your custom domains. Older protocol versions have known weaknesses and should not be accepted.
• Use managed certificates. Front Door managed TLS certificates auto-renew, which removes the risk of an expired certificate breaking your HTTPS enforcement.
• Mark cookies as Secure. Application-level cookies should carry the Secure and HttpOnly flags so they are never sent over plain HTTP and are not readable from JavaScript.
• Audit every endpoint, not just the main one. Staging, preview, and legacy endpoints are easy to forget and just as exploitable. Apply the same HTTPS enforcement everywhere.

Treat HTTPS enforcement at the edge as non-negotiable. The redirect costs nothing, breaks nothing when the origin is ready, and removes an entire class of interception attacks from your threat model.

Front Door is often the first thing an attacker probes because it is the public face of your application. Closing the HTTP door, forcing TLS end to end, and gating it in your pipeline turns a recurring audit finding into a solved problem.