All data sent over HTTP is visible and subject to compromise.
Example 1:

"supportsHttpsTrafficOnly": "false"

A publicly accessible Kubernetes API server can expose the organization to attack.

Example 1: The following example shows a template that defines a Kubernetes service cluster that does not restrict the range of IP addresses that are allowed to connect to the API server.

param location string = resourceGroup().location

resource example 'Microsoft.ContainerService/managedClusters@2020-02-01' = {
    name: 'TestCluster'
    location: location
    properties: {
        ...
        servicePrincipalProfile: {
            clientId: '422313d8-123a-41ea-8f8e-90821ff61c05'
            secret: 'xxxxxxxxxxxxxxxxx'
        }
    }
}

Debugging interfaces provide attackers with information that they can leverage for a more targeted attack.

Example 1: The following example template defines an Azure App Service with remote debugging enabled.

resource example 'Microsoft.Web/sites/config@2022-09-01' = {
    ...
    properties: {
        ...
        remoteDebuggingEnabled: true
    }
}

By default, Azure Blob Storage containers prevent anonymous access to their Blobs.

Insufficient access configurations expose systems and broaden an organization's attack surface. Resources open to public access might unintentionally leak sensitive data.

Example 1: The following example template defines an Azure Blob Storage container with the publicAccess property set to Container. This allows anonymous access to all of the container's blobs and data.

param storageAccountName string
param containerName string

resource example 'Microsoft.Storage/storageAccounts/blobServices/containers@2021-04-01' = {
    name: '${storageAccountName}/default/${containerName}'
    ...
    properties: {
        ...
        publicAccess: 'Container'
    }
}

Insufficient access configurations expose systems and broaden an organization's attack surface. Services open to interaction with the internet are subject to continuous scanning and probing by malicious entities.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published (e.g Heartbleed). Attackers can actively pursue and search for unpatched and exposed systems to exploit.

Example 1: The following example template defines an Azure Container Registry with unrestricted network access by enabling the property publicNetworkAccess and making no IP restrictions.

resource example 'Microsoft.ContainerRegistry/registries@2022-12-01' = {
    ...
    properties: {
        ...
        publicNetworkAccess: 'Enabled'
    }
}

Example 2: The following example template defines an Azure Container Registry with unrestricted network access by specifying a broad allow list for the networkRuleSet property.

resource example 'Microsoft.ContainerRegistry/registries@2022-12-01' = {
    ...
    properties: {
        ...
        publicNetworkAccess: 'Enabled'
        networkRuleSet: {
            defaultAction: 'Allow'
            ipRules: [
                {
                    action: 'Allow'
                    value: '*'
                }
            ]
        }
    }
}

Cross-Origin Resource Sharing, commonly referred to as CORS, is a technology that allows a domain to define a policy for its resources to be accessed by a web page hosted on a different domain. Historically, web browsers have restricted their domain resources from being accessed by scripts loaded from a different domain to abide by the same origin policy.
CORS provides a method for a domain to allow other domains and enable them to access its resources.

Be careful when defining a CORS policy because an overly permissive policy configured at the server level for a domain or a directory on a domain can expose more content for cross domain access than intended. CORS can enable a malicious application to communicate with a victim application inappropriately, which can lead to information disclosure, spoofing, data theft, relay, or other attacks.

Implementing CORS can increase an application's attack surface and should only be used when necessary.

Example 1: The following example template defines an overly permissive CORS policy for an Azure SignalR web application.

resource example 'Microsoft.SignalRService/SignalR@2022-02-01' = {
    ...
    properties: {
        ...
        cors: {
            ...
            allowedOrigins: [ '*' ]
        }
    }
}

Example 2: The following example template defines an overly permissive CORS policy for an Azure web application.

resource example 'Microsoft.Web/sites@2020-12-01' = {
    ...
    properties: {
        ...
        siteConfig: {
            ...
            cors: {
                ...
                allowedOrigins: [ '*' ]
            }
        }
    }
}

Example 3: The following example template defines an overly permissive CORS policy for an Azure Maps account.

resource example 'Microsoft.Maps/accounts@2021-12-01-preview' = {
    ...
    properties: {
        ...
        cors: {
            corsRules: [
                {
                    allowedOrigins: [ '*' ]
                }
            ]
        }
    }
}

Example 4: The following example template defines an overly permissive CORS policy for an Azure Cosmos DB account.

resource example 'Microsoft.DocumentDB/databaseAccounts@2023-04-15' = {
    ...
    properties: {
        ...
        cors: [
            {
                ...
                allowedOrigins: '*'
            }
        ]
    }
}

Example 5: The following example template defines an overly permissive CORS policy for an Azure storage blob service.

resource example 'Microsoft.Storage/storageAccounts/blobServices@2021-09-01' = {
    ...
    properties: {
        ...
        cors: {
            corsRules: [
                {
                    ...
                    allowedOrigins: [ '*' ]
                }
            ]
        }
    }
}

Relaxed access configurations expose systems and broaden an organization's attack surface. Services open to interaction with the internet are subjected to almost continuous scanning and probing by malicious entities.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published (e.g Heartbleed). Attackers can actively pursue and search for unpatched and exposed systems to exploit.

Example 1: The following example template defines an Azure Cosmos DB with unrestricted network access. The publicNetworkAccess property is set to Enabled and the IP address range includes all IPs.

resource example 'Microsoft.DocumentDB/databaseAccounts@2021-04-15' = {
    ...
    properties: {
        ...
        publicNetworkAccess: 'Enabled'
        ipRules: [
            {
                ipAddressOrRange: '0.0.0.0'
            }
        ]
    }
}