# Azure Storage Account HTTPS Not Enforced

> Azure storage accounts with supportsHttpsTrafficOnly set to false accept unencrypted HTTP requests to their endpoints. ZopNight fires RC-1322 only when the discoverer records https_only as "false" and abstains when the flag is absent, so every finding reflects a confirmed account configuration, not a guess.

Source: https://zop.dev/integrations/azure/recommendations/azure-storage-account-https-not-enforced
Updated: 2026-08-19

---

## 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

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

## Enforcing it

```bash
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.