HIGH api key exposureazure openai

Api Key Exposure in Azure Openai

How Api Key Exposure Manifests in Azure Openai

API key exposure in Azure OpenAI manifests through several Azure-specific patterns that developers must guard against. The most common scenario occurs when developers hardcode connection strings or keys directly into configuration files or environment variables that get committed to source control. Azure OpenAI uses a specific format for connection strings that includes the endpoint and key:

# Vulnerable: Hardcoded credentials in Python
from azure.core.credentials import AzureKeyCredential
import os

# Direct key exposure - never commit this to git!
OPENAI_API_KEY = "your-azure-openai-key-here"

client = AzureOpenAI(
    endpoint="https://myaccount.openai.azure.com/",
    api_key=OPENAI_API_KEY
)

Another Azure-specific exposure vector occurs through Azure App Service configuration. When developers use Azure's built-in Key Vault integration but fail to properly scope access, the application may inadvertently log or expose keys through Azure Monitor or Application Insights. The following pattern is dangerous:

// Vulnerable: Logging sensitive data in Azure environment
public async Task<string> GenerateContent(string prompt)
{
    var result = await _azureOpenAIClient.GetChatCompletionsAsync(
        engine: "text-davinci-003",
        messages: new ChatMessage[] { new ChatMessage("user", prompt) }
    );
    
    // Logging the entire response - includes request IDs that may contain key fragments
    _logger.LogInformation($"Azure OpenAI Response: {result}");
    return result;
}

Azure OpenAI's REST API also presents unique exposure risks. The service requires specific headers and endpoint formats that, if logged or exposed in error responses, can reveal the complete API key structure:

# Request structure that should never be logged
POST /openai/deployments/my-deployment/chat/completions HTTP/1.1
Host: myaccount.openai.azure.com
Authorization: Bearer YOUR_AZURE_OPENAI_KEY
Content-Type: application/json

{
  "messages": [
    { "role": "user", "content": "Hello" }
  ]
}

Azure OpenAI's specific deployment model adds another layer of complexity. Keys are scoped to specific deployments, and developers often create multiple deployment keys for different environments. When these keys are not properly rotated or scoped, a single exposed key can compromise multiple services across an Azure subscription.

Azure Openai-Specific Detection

Detecting API key exposure in Azure OpenAI requires understanding its unique authentication patterns and deployment structure. Azure OpenAI uses a two-part authentication system: the subscription key and the deployment-specific key. middleBrick's scanner identifies these patterns through several Azure-specific checks:

Configuration File Analysis

The scanner examines common Azure configuration locations for exposed keys:

# middleBrick scan output for Azure OpenAI exposure
$ middlebrick scan https://myapp.azurewebsites.net

=== Azure OpenAI API Key Exposure ===
Severity: HIGH
Location: appsettings.json (line 42)
Issue: Hardcoded Azure OpenAI key detected
Recommendation: Use Azure Key Vault or environment variables

=== Deployment Key Structure ===
Detected Azure OpenAI deployment: my-deployment
Endpoint: https://myaccount.openai.azure.com/
Key format: Valid Azure OpenAI key structure

Runtime Request Monitoring

middleBrick actively monitors network traffic to detect Azure OpenAI API calls that may expose keys:

// Detected in network traffic
{
  "endpoint": "https://myaccount.openai.azure.com/",
  "headers": {
    "Authorization": "Bearer sk-my-key-here",
    "api-key": "your-azure-openai-key"
  }
}

Azure-Specific Patterns

The scanner looks for Azure-specific exposure patterns:

  • Azure App Service configuration files with embedded keys
  • Azure Function app settings containing OpenAI credentials
  • Azure DevOps pipeline variables with exposed keys
  • Azure Monitor logs containing API key fragments

LLM-Specific Detection

middleBrick's unique LLM security capabilities also detect Azure OpenAI-specific risks:

=== Azure OpenAI LLM Security ===
Severity: MEDIUM
Issue: System prompt contains deployment-specific instructions
Risk: Potential prompt injection via Azure OpenAI deployment
Recommendation: Validate and sanitize all user inputs

The scanner identifies Azure OpenAI's specific API structure, including deployment endpoints and the way keys are scoped to specific models and regions within Azure's infrastructure.

Azure Openai-Specific Remediation

Remediating API key exposure in Azure OpenAI requires leveraging Azure's native security features and following Azure-specific best practices. The most secure approach uses Azure Key Vault with managed identity:

Azure Key Vault Integration

# Secure: Azure Key Vault with managed identity
from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient
from azure.core.credentials import AzureKeyCredential
import os

# Use managed identity - no hardcoded keys
credential = DefaultAzureCredential()
key_vault_uri = os.environ["KEY_VAULT_URI"]
secret_client = SecretClient(key_vault_uri, credential)

# Fetch Azure OpenAI key securely
azure_openai_key = secret_client.get_secret("azure-openai-key").value

client = AzureOpenAI(
    endpoint="https://myaccount.openai.azure.com/",
    api_key=azure_openai_key
)

Azure App Service Configuration

// Secure: Azure App Service with Key Vault references
public class AzureOpenAIClient
{
    private readonly string _endpoint;
    private readonly AzureKeyCredential _credential;
    
    public AzureOpenAIClient(IConfiguration configuration)
    {
        _endpoint = configuration["AzureOpenAI:Endpoint"];
        
        // Configuration references Key Vault - no keys in code
        var keyVaultUri = configuration["AzureOpenAI:KeyVaultUri"];
        var keyName = configuration["AzureOpenAI:KeyName"];
        
        // Key Vault reference resolves at runtime
        var keyVaultCredential = new DefaultAzureCredential();
        var secretClient = new SecretClient(new Uri(keyVaultUri), keyVaultCredential);
        var keySecret = secretClient.GetSecret(keyName);
        
        _credential = new AzureKeyCredential(keySecret.Value);
    }
}

Azure Functions Security

// Secure: Azure Function with managed identity
[FunctionName("GenerateContent")]
public static async Task<HttpResponseData> Run(
    [HttpTrigger(AuthorizationLevel.Function, "post", Route = "content")] HttpRequestData req,
    FunctionContext executionContext)
{
    var azureCredential = new DefaultAzureCredential();
    var keyVaultClient = new SecretClient(new Uri("https://myvault.vault.azure.net/"), azureCredential);
    
    var openaiKey = keyVaultClient.GetSecret("azure-openai-key").Value;
    var openaiClient = new AzureOpenAIClient(
        endpoint: "https://myaccount.openai.azure.com/",
        api_key: openaiKey
    );
    
    // Process request
}

Azure DevOps Pipeline Security

# Secure: Azure DevOps with Key Vault integration
steps:
- task: AzureKeyVault@2
  inputs:
    azureSubscription: 'MyAzureSubscription'
    keyVaultName: 'my-key-vault'
    secretsFilter: 'AzureOpenAIKey'
  
- script: |
    echo "Azure OpenAI key: $(AzureOpenAIKey)"
    # Use key in subsequent steps - never logged

Key Rotation and Monitoring

# Azure CLI commands for key management
# Create new key
az keyvault secret set --name azure-openai-key --value "new-key-value" --vault-name my-key-vault

# Update Azure OpenAI deployment (if needed)
az cognitiveservices account keys renew --name my-openai-account --resource-group my-resource-group

# Monitor for key exposure
az monitor log-analytics query --workspace MY_WORKSPACE_ID --query "traces | where message contains 'openai'"

Azure Policy Enforcement

// Azure Policy to prevent key exposure
{
  "policyRule": {
    "if": {
      "allOf": [
        { "field": "type", "equals": "Microsoft.Web/sites/config" },
        { "field": "Microsoft.Web/sites/config/appSettings", "contains": "OPENAI_API_KEY" }
      ]
    },
    "then": {
      "effect": "deny"
    }
  }
}

These Azure-specific remediation patterns ensure that API keys are never exposed in code, configuration files, or logs, while maintaining the functionality required for Azure OpenAI integration.

Frequently Asked Questions

How does Azure OpenAI's authentication differ from OpenAI's standard API?
Azure OpenAI uses a subscription-based model where you get a dedicated endpoint (e.g., https://myaccount.openai.azure.com/) and keys that are scoped to your Azure subscription. Unlike OpenAI's public API, Azure keys are tied to specific deployments within your Azure account, and you can use your own data and models within the Azure infrastructure. The authentication headers are similar but the endpoint structure and key format are Azure-specific.
Can middleBrick scan Azure OpenAI endpoints that require authentication?
Yes, middleBrick can scan authenticated Azure OpenAI endpoints. You can provide the necessary credentials through environment variables or configuration files, and middleBrick will use these to authenticate while scanning. The tool is designed to test the authenticated attack surface, including BOLA/IDOR vulnerabilities, privilege escalation paths, and prompt injection vulnerabilities specific to Azure OpenAI's implementation.