Cors Wildcard on Azure

CORS wildcard misconfigurations in Azure environments create dangerous attack vectors that can expose your APIs to cross-origin abuse. In Azure, this issue commonly appears when developers configure CORS policies too broadly in Azure App Service, Azure Functions, or API Management.

The most dangerous pattern occurs when developers use wildcard origins (*) without restrictions. This allows any website to make requests to your Azure-hosted API, potentially exposing sensitive data or enabling malicious actions. For example:

services.AddCors(options =>
    options.AddPolicy("AllowAll", builder =>
        builder.AllowAnyOrigin()
               .AllowAnyMethod()
               .AllowAnyHeader()));

In Azure App Service, this configuration might seem harmless during development but becomes catastrophic in production. Attackers can host malicious sites that make authenticated requests to your Azure API using the victim's credentials, exploiting the trust established between your API and legitimate origins.

Another Azure-specific manifestation occurs with Azure Functions CORS settings. When developers configure CORS in the Azure portal or Azure CLI without understanding the implications:

az functionapp cors add 
    --resource-group MyResourceGroup 
    --name MyFunctionApp 
    --allowed-origins "*"

This command opens your Azure Function to any origin, enabling various attacks including data exfiltration and credential theft.

Azure API Management presents unique CORS wildcard risks. When policies are configured with overly permissive settings:

<inbound>
    <cors>
        <allowed-origins>
            <origin>*</origin>
        </allowed-origins>
        <allowed-methods>
            <method>*</method>
        </allowed-methods>
        <allowed-headers>
            <header>*</header>
        </allowed-headers>
        <expose-headers>
            <header>*</header>
        </expose-headers>
    </cors>
</inbound>

This configuration allows any website to interact with your API through Azure API Management, potentially bypassing security controls intended for specific trusted origins.

Azure-specific attack scenarios include:

• Cross-tenant data exposure: A malicious tenant in the same Azure subscription could exploit wildcard CORS to access APIs from other applications
• Azure AD token theft: Attackers can use malicious sites to capture tokens from legitimate users accessing your Azure-hosted API
• Azure Storage CORS abuse: Misconfigured Azure Blob Storage CORS policies can expose sensitive data to any origin

The impact is particularly severe in Azure environments because of the tight integration between services. A CORS wildcard in one Azure service can cascade into broader security issues across your entire Azure ecosystem.

Detecting CORS wildcard misconfigurations in Azure requires both manual inspection and automated scanning. For Azure App Service and Functions, start by examining your CORS configuration:

# Check Azure App Service CORS settings
az webapp cors show --resource-group MyResourceGroup --name MyWebApp

# Check Azure Functions CORS settings
az functionapp cors show --resource-group MyResourceGroup --name MyFunctionApp

# Check Azure API Management CORS policies
az apim policy show --resource-group MyResourceGroup --name MyAPIManagement

Look for configurations showing allowed-origins containing * or excessively broad patterns like https://*.example.com.

For code-based detection, scan your Azure application's CORS configuration:

public static bool HasWildcardCORS(this IConfiguration configuration)
{
    var allowedOrigins = configuration.GetSection("Cors:AllowedOrigins").Get<string[]>();
    return allowedOrigins?.Any(origin => origin == "*" || origin.EndsWith(".*")) ?? false;
}

// In Azure Functions startup
if (config.HasWildcardCORS())
{
    log.LogWarning("CORS wildcard configuration detected - potential security risk");
}

middleBrick provides specialized Azure CORS detection that goes beyond basic configuration checking. It actively tests your Azure-hosted endpoints for CORS wildcard vulnerabilities by:

• Analyzing Azure-specific CORS headers like Access-Control-Allow-Origin and Access-Control-Allow-Credentials
• Testing wildcard combinations with authentication headers to identify credential leakage
• Checking Azure-specific endpoints like /api/ routes in App Service and Functions

To scan with middleBrick:

# Scan Azure App Service URL
middlebrick scan https://myapp.azurewebsites.net/api/data

# Scan Azure Function URL
middlebrick scan https://myfunctionapp.azurewebsites.net/api/ProcessOrder

# Scan Azure API Management endpoint
middlebrick scan https://myapim.management.azure-api.net/api/v1/orders

middleBrick's Azure-specific detection identifies not just wildcard origins but also dangerous combinations like Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true, which is explicitly forbidden by the CORS specification and creates severe security vulnerabilities.

For comprehensive Azure security, integrate middleBrick into your CI/CD pipeline:

name: API Security Scan
on: [push, pull_request]
jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Scan Azure API
        run: |
          npm install -g middlebrick
          middlebrick scan https://myapp.azurewebsites.net/api --threshold B
        continue-on-error: true

This ensures CORS wildcard misconfigurations are caught before deployment to Azure production environments.

Remediating CORS wildcard issues in Azure requires a security-first approach that balances functionality with protection. For Azure App Service and Functions, implement origin-specific CORS policies:

services.AddCors(options =>
{
    options.AddPolicy("Production", builder =>
    {
        builder.WithOrigins(
            "https://myapp.com",
            "https://admin.myapp.com",
            "https://partner.example.com"
        )
        .WithMethods("GET", "POST", "PUT", "DELETE")
        .WithHeaders("Content-Type", "Authorization", "X-Custom-Header")
        .AllowCredentials();
    });
});

In Azure Functions, configure CORS in the host.json file with explicit origins:

{
  "version": "2.0",
  "cors": {
    "allowedOrigins": [
      "https://myapp.com",
      "https://admin.myapp.com"
    ],
    "allowedMethods": ["GET", "POST", "PUT", "DELETE"],
    "allowedHeaders": ["Content-Type", "Authorization", "X-Custom-Header"],
    "exposedHeaders": ["X-Custom-Header"],
    "supportsCredentials": true
  }
}

For Azure API Management, use policy-based CORS with specific origins:

<inbound>
    <cors>
        <allowed-origins>
            <origin>https://myapp.com</origin>
            <origin>https://admin.myapp.com</origin>
        </allowed-origins>
        <allowed-methods>
            <method>GET</method>
            <method>POST</method>
            <method>PUT</method>
            <method>DELETE</method>
        </allowed-methods>
        <allowed-headers>
            <header>Content-Type</header>
            <header>Authorization</header>
            <header>X-Custom-Header</header>
        </allowed-headers>
        <expose-headers>
            <header>X-Custom-Header</header>
        </expose-headers>
        <allow-credentials/>
    </cors>
</inbound>

Azure Storage CORS requires similar specificity. In Azure Blob Storage, configure CORS rules in the Azure portal or via Azure CLI:

az storage cors add 
    --services b 
    --origins "https://myapp.com" "https://admin.myapp.com"
    --methods GET POST PUT DELETE
    --headers "Content-Type" "Authorization"
    --exposed-headers "X-Custom-Header"
    --max-age 200

For Azure API Management, implement environment-specific CORS policies using the context variable:

<choose>
    <when condition="@(context.Deployment.Environment == 'production')">
        <cors>
            <allowed-origins>
                <origin>https://myapp.com</origin>
            </allowed-origins>
            <allowed-methods>
                <method>GET</method>
                <method>POST</method>
            </allowed-methods>
            <allowed-headers>
                <header>Content-Type</header>
                <header>Authorization</header>
            </allowed-headers>
        </cors>
    </when>
    <otherwise>
        <cors>
            <allowed-origins>
                <origin>https://dev.myapp.com</origin>
            </allowed-origins>
        </cors>
    </otherwise>
</choose>

Implement runtime CORS validation in Azure Functions:

public static class Function1
{
    [FunctionName("ProcessOrder")]
    public static async Task<HttpResponseData> Run(
        [HttpTrigger(AuthorizationLevel.Function, "post", Route = null)] HttpRequestData req,
        FunctionContext executionContext)
    {
        var allowedOrigins = new[]
        {
            "https://myapp.com",
            "https://admin.myapp.com"
        };

        var origin = req.Headers["Origin"].FirstOrDefault();
        if (!string.IsNullOrEmpty(origin) && allowedOrigins.Contains(origin))
        {
            var response = req.CreateResponse(HttpStatusCode.OK);
            response.Headers.Add("Access-Control-Allow-Origin", origin);
            response.Headers.Add("Access-Control-Allow-Credentials", "true");
            return response;
        }

        return req.CreateResponse(HttpStatusCode.Forbidden);
    }
}

For Azure Service Bus and Event Grid integrations, ensure CORS policies don't inadvertently expose messaging endpoints. Configure only necessary origins and methods for webhook subscriptions.

middleBrick's remediation guidance includes specific Azure configuration examples and severity-based recommendations. For critical findings, it provides exact policy configurations for your Azure environment, reducing remediation time from hours to minutes.