Storage accounts accepting unencrypted HTTP traffic

What travels in the clear

A storage account with secure transfer disabled answers REST calls made over plain http://. Everything in those requests (blob contents, table rows, queue messages, and the SAS tokens authorizing them) crosses the network unencrypted. An attacker positioned anywhere on the path can read the data, and worse, capture a SAS token and replay it over HTTPS later with full legitimacy. In-transit interception is invisible in your logs: the request looks identical to a normal one, which is why auditors treat this as a configuration failure rather than waiting for evidence of abuse.

Detection is a control-plane fact, not an inference

The Azure discoverer reads properties.supportsHttpsTrafficOnly off the account’s ARM record and stamps https_only into the resource’s metadata in both polarities. RC-1322 fires only on the literal string “false” and abstains when the key is absent, so the rule proves the condition directly from provider state. There is no traffic sampling and no heuristic involved. An earlier version of this rule read a customer-controlled tag that no producer ever wrote, meaning it could never fire; the current metadata contract fixed that. Detection runs under the built-in Reader role through Azure Resource Graph.

The clients that break when you flip it

Enforcing secure transfer rejects HTTP immediately, with no grace period. Two client populations tend to fail: SDK code with an explicit http:// endpoint in its connection string, and Azure Files mounts using SMB without encryption. Neither shows up until the moment of enforcement, so check diagnostic logs for insecure requests before making the change rather than after the pager goes off.

Audit every account in one query

az storage account list \
  --query "[?enableHttpsTrafficOnly == \`false\`].{name:name, rg:resourceGroup}" \
  -o table

Enforcing it

az storage account update -n <account> -g <rg> --https-only true

Accounts created through recent API versions default to requiring secure transfer, so findings from this rule usually point at accounts that predate the default or were deliberately relaxed. The second case is worth a conversation before you flip the switch. There is no dollar saving attached; the rule exists because an account-level toggle closes an entire class of in-transit exposure in one reversible step.