App Service sites still accepting plain HTTP because httpsOnly is off
What does ZopNight detect here?
HTTPS-only left off an Azure App Service means the site still answers plain HTTP, exposing traffic to interception. Rule RC-1311 reads the per-site httpsOnly property the discoverer stamps as https_only and fires high severity only on an explicit "false". The fix is a single toggle plus a minimum TLS version of 1.2.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1311 |
| Category | compliance |
| Severity | high |
| Metric | none — pure configuration read |
| Source | appservice_ssl.go |
Where it applies
Plain HTTP into production apps
Every App Service and Function App serves both http:// and https:// until told
otherwise: httpsOnly is off by default. In that state, a session cookie or bearer token
sent by a client that followed an http link travels the network unencrypted before any
redirect your application issues; on a shared network, that is an interception waiting to
happen. Auditors treat cleartext transport of credentials as a finding regardless of whether
anyone demonstrably exploited it, which is why the rule carries high severity despite the
one-line fix.
A per-site property, not a plan property
The signal is the site’s own properties.httpsOnly, which the discoverer surfaces through
Azure Resource Graph (a Reader-role read) and stamps as https_only. Rule RC-1311 fires only
on an explicit "false" and abstains when the property was not projected. An earlier version
was doubly dead: it read an ssl_enforced tag no producer wrote, and it was bound to the App
Service plan, while httpsOnly lives on microsoft.web/sites, which the discoverer maps to
the functionapp type, so the rule was retargeted there. Web apps and function apps are both
covered under that one canonical type.
One toggle, no rebuild
Enforcement is a platform-level 308 redirect switched on per site: no code change, no certificate work for the default hostname, and effective immediately:
az webapp update -n <app> -g <rg> --set httpsOnly=trueThe single caller class worth checking first is non-browser clients hardcoded to http://
URLs that do not follow redirects; fix those URLs, then flip the switch.
Beyond the toggle: minimum TLS
HTTPS-only says nothing about which TLS. Pair the toggle with a floor of TLS 1.2 under the site’s TLS/SSL settings so legacy 1.0/1.1 handshakes are refused too, and add certificates for any custom domains. Neither is part of what this rule can verify (it proves only the httpsOnly state), but they belong to the same remediation visit.
Audit httpsOnly across a subscription
az webapp list --query "[?httpsOnly==\`false\`].{name:name, rg:resourceGroup}" -o tableThe same query works with az functionapp list, since function apps carry the identical
property, and every row returned is a site rule RC-1311 will report.