How to fix “API App should only be accessible over HTTPS” finding from Microsoft Defender for cloud? Follow this step by step guide.
This finding indicates that your Azure App Service allows connectivity over HTTP and HTTPS, where it should allow only HTTPS. This might seam like not much of a difference and in functionality you might see absolutely no change, but there is a big difference in security. HTTP traffic is unencrypted and visible to every party and every device that is able to see the network packets (like ISPs, Access points or even simply – other users of the network you are connected to). Every token or secret sent over this channel is something that can be easily retrieved by other parties. But that is not where the risk ends. Without TLS, server and client has no possibility of confirming that the sent packets are delivered to the other without any changes. Third parties can tamper with the packets.
To fix this policy violation from the Azure Portal, follow the steps:
1) Go your Api App in Azure Portal
2) Go to “General Settings”
3) Switch “HTTPS Only” to “On”
4) Click “Save”
Enforcing HTTPS on Api APP via Powershell
Below commands allow to enforce HTTPS on Api APP:
### looking for Api App named "api12345" and resourse group "api12345_group". Replace with your values
PS /home/user> Get-AzWebApp -Name api12345
Name State ResourceGroup EnabledHostNames Location
---- ----- ------------- ---------------- --------
api12345 Running api12345_group {api12345.azurewebsites.net, api12345.scm.azurewe… Central US
### checking if HTTPS is enforced
PS /home/user> (Get-AzWebApp -Name api12345).HttpsOnly
False
### Enforcing HTTPS
PS /home/user> Set-AzWebApp -name api12345 -ResourceGroupName api12345_group -HttpsOnly $true
Name State ResourceGroup EnabledHostNames Location
---- ----- ------------- ---------------- --------
api12345 Running api12345_group {api12345.azurewebsites.net, api12345.scm.azurewe… Central US
###Validating if HTTPS is enforced
PS /home/user> (Get-AzWebApp -Name api12345).HttpsOnly
True
Potential abuse of API App misconfiguration
In a scenario where the API calls originates from the machine of an employee working from home – all the request and response data is leaked to the owner of the Access Point, Internet Service Provider and potentially other users of the network.
Take note that even if you trust in good intentions of your service providers, there are attacks that might target devices in the chain of communication. Wi-Fi Evil Twin attack is all about an attacker setting up a replica of an original Access Point. Your device having two Access Points in range with the same signature, will pick up the one that has a stronger signal (thinking that it’s the one that is closer). Yet an attacker doesn’t need to comply with rules limiting the strength of the Wi-Fi transmitter, so he can make his device have a stronger signal from across the street, than your original Access Point sitting in the same room. This forces your device to connect to a rogue Access Point. And all the HTTP traffic is visible by the controller of that Access Point. This is why HTTP misconfigurations have such a high impact, even though they are relatively easy to fix.
Even if API is not available to public, and is only reachable from the internal network of the company – there is no reason to put more trust in networking devices in between the client and server. The rule of minimum-required-permissions should apply to devices too.
This guide is a part of a series Fixing Defender Security Recommendations. Find out how to implement all security recommendations in your environment!