Enforce HTTPS-only traffic by requiring secure transport on the storage account so clients cannot use plain HTTP. Check application dependencies before turning it on, because older integrations may fail. Then verify that all access paths, including service connections and scripts, use HTTPS and that no exceptions remain for sensitive storage.
What “HTTPS-only” means on an Azure Storage account
Azure Storage has a setting that requires secure transport for every request to the account. When you enable it, clients must use HTTPS, which means traffic is encrypted in transit and plain HTTP requests are rejected. That control is simple, but it only works if every application, script, connector, and SDK path is compatible with secure transport.
For teams that use Azure broadly, the setting belongs in the same baseline as other storage hardening measures. The Microsoft Azure Security Guide places storage security alongside policy guardrails, networking, and identity controls, which is the right way to think about this setting: it is one part of a wider cloud security baseline, not a standalone checkbox.
Where HTTPS-only enforcement is configured and what it changes
The control is applied at the storage account level, so it affects blobs, files, queues, and tables served by that account. Once enabled, requests made over HTTP should fail rather than quietly downgrading to an unencrypted channel. That matters for service-to-service access, browser-based downloads, backup jobs, and automation that still points at older endpoints or hardcoded URLs.
In practice, the main change is not the API surface, but the transport assumption. You are telling every consumer that the account will only accept secure transport. That makes the setting especially useful for sensitive storage, where accidental cleartext traffic would be a confidentiality and compliance problem, but it also means you need to know which consumers are still making legacy calls.
For larger Azure estates, this control is often enforced alongside other cloud guardrails. The Azure-focused guidance in the Cloud Security Guide aligns this kind of setting with policy-driven configuration, which is important because ad hoc per-account hardening tends to drift over time.
What to check before you switch it on
Before enforcing HTTPS-only traffic, inventory every access path that touches the storage account. That includes application code, scripts, CI/CD jobs, third-party integrations, backup tools, and any service connection that may still use an older endpoint or a manually constructed URL. The obvious risk is breakage, but the deeper issue is hidden dependency on insecure defaults that have been tolerated for years.
It is also worth checking whether the account is being used in patterns that already indicate broader storage exposure. The Microsoft Azure storage exposure 2024 case is a reminder that misconfigured storage can expose credentials and internal files, which is exactly why transport hardening should be paired with content review and access review rather than treated as a cosmetic setting.
If your estate includes shared access signatures or other time-bound access material, validate that the clients consuming them are already HTTPS-capable. The Microsoft SAS token exposure 2023 article shows how an over-permissive access token can amplify storage exposure, so transport enforcement should be combined with token scope and lifetime discipline.
Risk and Threat Considerations
HTTP on storage is risky because it removes transport confidentiality and opens the door to passive interception, URL tampering, and accidental leakage through logs or proxies that see the request in cleartext. In mixed environments, the bigger danger is not a deliberate attacker but a forgotten legacy integration that keeps sending sensitive data over an unprotected channel.
Failure mechanism: A client, script, or service keeps using plain HTTP, and the storage account either accepts the request or the team leaves an exception in place for compatibility. That creates a weak link where secrets, data, or access tokens can travel without encryption and where insecure dependencies persist unnoticed.
Impact: Sensitive storage can be exposed in transit, legacy paths can become a compromise point, and the organisation may think it has enforced secure transport when one or more access paths still bypass it. In regulated or high-sensitivity workloads, that can also undermine audit evidence for data-in-transit protection.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-3 — Data Protection | HTTPS-only storage protects data in transit from exposure. |
| Recommendation — Require secure transport for storage access and verify no cleartext paths remain. | ||
| NIST SP 800-53 Rev 5 | SC-8 — Transmission Confidentiality and Integrity | Forces encrypted transit for storage requests and rejects cleartext HTTP. |
| Recommendation — Enforce protected transmission for storage traffic and confirm all clients use HTTPS. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Secure transport is a technical protection for data in transit to cloud storage. |
| Recommendation — Apply secure transport requirements to storage endpoints and validate implementation. | ||
| CSA Cloud Controls Matrix | DCS — Datacenter Security | Cloud storage transport security is part of protecting cloud-hosted data services. |
| Recommendation — Set storage transport controls and confirm service integrations comply. | ||
Practitioner Guidance
What to verify: Confirm that the storage account setting is enabled, then validate every producer and consumer path, not just the primary application. The most common miss is an auxiliary script, automation job, or vendor connector that was never updated when the main application was modernised.
Decision rule: If any path still fails when HTTPS-only is enabled, fix or retire that dependency before rollout; do not leave the control off just to preserve convenience. If the data is sensitive, an exception should be treated as a temporary remediation item, not an accepted operating state.
Practitioner takeaway: Enforcing HTTPS-only on Azure Storage is easy to configure but easy to get wrong operationally, so success depends on proving that every real access path already speaks HTTPS before you flip the switch.
Related resources from NHI Mgmt Group
- How should security teams reduce the risk created by Azure Storage Accounts that allow Shared Key access by default?
- What is the difference between Azure AD authentication and Shared Key authorization for Storage Accounts?
- Why does Azure Shared Key authorization create such a large attack surface for storage accounts?
- What do teams get wrong about granting read access to Azure storage accounts?