Broken Authentication on Azure

Broken authentication in Azure environments often stems from misconfigured identity and access management (IAM) settings. A common pattern involves Azure Functions or Web Apps where developers inadvertently expose endpoints without proper authentication checks. Consider this vulnerable Azure Function code:

using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;

public static class VulnerableFunction
{
    [FunctionName("GetUserDetails")]
    public static IActionResult Run(
        [HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = "user/{id}")] HttpRequest req,
        string id)
    {
        // NO authentication check!
        var user = Database.GetUserById(id);
        return new OkObjectResult(user);
    }
}

The AuthorizationLevel.Anonymous attribute allows anyone to call this endpoint, enabling attackers to enumerate user data through IDOR (Insecure Direct Object Reference) attacks. This is particularly dangerous in multi-tenant Azure environments where tenant isolation depends on proper authentication.

Another Azure-specific pattern involves Azure API Management where policies might be misconfigured. A vulnerable policy configuration could look like:

<policies>
    <!-- Missing authentication validation -->
    <inbound>
        <base />
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
    </outbound>
</policies>

Without validating JWT tokens or API keys, any client can access backend services. This becomes critical when Azure services like Cosmos DB or Storage Accounts are exposed through API Management without proper access controls.

Azure AD misconfigurations also contribute to broken authentication. A common mistake is using overly permissive app registrations:

var app = ConfidentialClientApplicationBuilder.Create(clientId)
    .WithClientSecret(clientSecret)
    .WithAuthority("https://login.microsoftonline.com/organizations")
    .Build();

// Missing: .WithTenantId(tenantId) for multi-tenant isolation

This allows authentication from any Azure AD tenant, potentially enabling unauthorized access across organizational boundaries.

Detecting broken authentication in Azure requires both manual code review and automated scanning. For Azure Functions, examine the function.json files and authorization attributes. Vulnerable configurations often show authLevel: "anonymous" or missing authentication middleware.

middleBrick's Azure-specific scanning identifies these patterns through black-box testing. The scanner attempts unauthenticated access to endpoints and analyzes responses for sensitive data exposure. For Azure Functions, it tests various HTTP methods and examines CORS configurations that might inadvertently expose endpoints.

Azure API Management policies can be audited using the Azure CLI:

az apim api list --resource-group myResourceGroup --service-name myAPIM
az apim api show-policy --resource-group myResourceGroup --api-id myAPI --format json

Look for missing <validate-jwt> or <check-header> policies that should validate incoming tokens or API keys.

For Azure AD applications, audit app registrations using:

az ad app show --id <app-id>

Check for overly permissive signInAudience settings and missing group-based access controls. The accessTokenAcceptedVersion property should be explicitly set to avoid version ambiguity.

middleBrick's continuous monitoring (Pro plan) can automatically scan your Azure-hosted APIs on a schedule, alerting you when authentication controls are missing or misconfigured. The scanner tests for common Azure-specific vulnerabilities like Cosmos DB endpoint exposure and Storage Account key leakage.

Fixing broken authentication in Azure requires implementing proper identity controls at multiple layers. For Azure Functions, start by securing endpoints:

using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Identity.Web;

public static class SecureFunction
{
    [FunctionName("GetUserDetails")]
    public static async Task Run(
        [HttpTrigger(AuthorizationLevel.Function, "get", Route = "user/{id}")] HttpRequest req,
        string id,
        [FromServices] ITokenAcquisition tokenAcquisition)
    {
        // Validate JWT token
        var token = await tokenAcquisition.GetAccessTokenForUserAsync(
            new[] { "https://graph.microsoft.com/.default" });
        
        // Verify user permissions
        var userId = req.HttpContext.User.FindFirst(ClaimTypes.NameIdentifier).Value;
        if (!await Database.UserHasAccess(userId, id))
        {
            return new UnauthorizedResult();
        }
        
        var user = await Database.GetUserById(id);
        return new OkObjectResult(user);
    }
}

For Azure API Management, implement proper JWT validation:

<policies>
    <inbound>
        <base />
        <validate-jwt
            header-name="Authorization"
            failed-validation-httpcode="401"
            failed-validation-error-message="Unauthorized. Access token is missing or invalid."
            require-expiration-time="true"
            require-signed-tokens="true"
            clock-skew="PT5M">
            <openid-config url="https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration" />
            <audiences>
                <audience>api://your-api-identifier</audience>
            </audiences>
        </validate-jwt>
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
    </outbound>
</policies>

Azure AD application security should include proper multi-tenant controls:

var app = ConfidentialClientApplicationBuilder.Create(clientId)
    .WithClientSecret(clientSecret)
    .WithTenantId(tenantId) // Explicitly set tenant
    .WithRedirectUri(redirectUri)
    .Build();

// Configure permissions with least privilege
var scopes = new[] { "User.Read" }; // Avoid .default wildcard

For Azure Storage Accounts, use Shared Access Signatures (SAS) with minimal permissions:

BlobSasBuilder sasBuilder = new BlobSasBuilder()
{
    BlobContainerName = containerName,
    Resource = "c",
    ExpiresOn = DateTimeOffset.UtcNow.AddHours(1)
};

sasBuilder.SetPermissions(BlobContainerSasPermissions.Read); // Least privilege

middleBrick's remediation guidance includes specific Azure security best practices for each finding category, helping you implement these fixes correctly.