[← Back to Reviews Index](../Stewards%20Reviews%20Index.md) # API Configuration Review — Azure-AI-RAG-CSharp-Semantic-Kernel-Functions | Field | Value | |---|---| | **Project** | Azure-AI-RAG-CSharp-Semantic-Kernel-Functions | | **Steward** | API Config Steward (`api-config-steward`) | | **Run Date** | 2026-03-21 | | **Target** | `src/ChatAPI` (C# / ASP.NET Core — net8.0) | | **Critical** | 1 | | **Notable** | 7 | | **Minor** | 3 | | **Info** | 1 | | **Total** | 12 | --- ## 1. Configuration Architecture Overview The `ChatAPI` project is a single-project ASP.NET Core 8 Web API. Configuration is consumed exclusively through raw `IConfiguration` — either via `builder.Configuration["Key"]` in `Program.cs` or through `IConfiguration` injected directly into service constructors. The application reads the following configuration keys at runtime: | Key | Consumer | Purpose | |---|---|---| | `CosmosDb_ConnectionString` | `Program.cs` (line 23) | CosmosDB client construction | | `CosmosDb_Database` | `ProductData`, `ChatHistoryData`, `GenerateProductInfo` | CosmosDB database name | | `CosmosDb_ProductContainer` | `ProductData`, `GenerateProductInfo` | Product container name | | `CosmosDb_ChatContainer` | `ChatHistoryData` | Chat history container name | | `AZURE_OPENAI_ENDPOINT` | `Program.cs` (line 28) | Azure OpenAI service endpoint URI | | `AZURE_OPENAI_DEPLOYMENT` | `Program.cs` (line 45) | Chat completion deployment name | | `AZURE_OPENAI_EMBEDDING` | `Program.cs` (line 46) | Embedding model deployment name | | `AZURE_AI_SEARCH_ENDPOINT` | `Program.cs` (lines 49, 54) | Azure AI Search endpoint URI | | `AZURE_AI_SEARCH_INDEX` | `Program.cs` (line 51) | Search index name | | `APPLICATIONINSIGHTS_CONNECTION_STRING` | `Program.cs` (line 67) | Application Insights telemetry | None of these keys are defined in `appsettings.json`, have documented defaults, or are bound to typed options classes. There is no startup validation. All configuration is expected to arrive at runtime via environment variables or container secrets, but this contract is undocumented and unenforced. --- ## 2. Options Pattern Assessment **Rating: Not implemented.** The project does not use `IOptions`, `IOptionsMonitor`, or `IOptionsSnapshot` anywhere. All configuration access is through raw `IConfiguration` — either directly in `Program.cs` at service-registration time, or through `IConfiguration` injected as a constructor parameter into `ProductData`, `ChatHistoryData`, and `GenerateProductInfo`. Key problems: - `ProductData` (line 9-10) reads `CosmosDb_Database` and `CosmosDb_ProductContainer` in its constructor. If either key is absent, the value will be `null` and the `!` null-forgiving operator will silently store a null string, producing a `NullReferenceException` or a CosmosDB exception at the first actual operation. - `ChatHistoryData` (lines 24-26) follows the same pattern. - `GenerateProductInfo` (lines 29-30) follows the same pattern. - `Program.cs` (lines 23, 28, 45-51, 67) uses `builder.Configuration["Key"]!` directly, relying on null-forgiving operators with no validation that the values are present or structurally valid. There are no options classes (`CosmosDbOptions`, `OpenAIOptions`, `AzureSearchOptions`) registered via `services.Configure()`. --- ## 3. Configuration Structure Assessment **Rating: Minimal.** Only one configuration file exists: `src/ChatAPI/appsettings.json`. Its content is limited to standard logging and host settings: ```json { "Logging": { "LogLevel": { "Default": "Information", "Microsoft.AspNetCore": "Warning" } }, "AllowedHosts": "*" } ``` Problems: - No `appsettings.Development.json` — there is no documented development configuration, no example configuration, and no environment-specific logging or service overrides. - No `appsettings.Production.json` — no production-tier overrides (e.g., stricter log levels, disabled Swagger, restricted CORS). - The ten configuration keys the application actually requires are entirely absent from `appsettings.json`. There are no placeholder values (e.g., `""`), no comments, and no schema annotation. A developer cloning the repository has no way to discover what configuration values are required without reading the source code. --- ## 4. Secrets Management Assessment **Rating: Partially acceptable — no secrets committed; integration missing.** Positive: `appsettings.json` contains no committed secrets, API keys, or connection strings. The application relies on environment variables (standard Azure Container Apps / ACA pattern) and `DefaultAzureCredential` for identity-based access to Azure OpenAI and Azure AI Search. Problems: - No Azure Key Vault integration. `Program.cs` does not call `AddAzureKeyVault()`. For the `CosmosDb_ConnectionString` — a sensitive connection string — Key Vault would be the appropriate source in production. - No `dotnet user-secrets` configuration for local development. The `.csproj` has no `` element. Developers are required to set environment variables locally, but this is not documented anywhere in the repository. - The `CosmosDb_ConnectionString` is consumed as a plain string from configuration (line 23 of `Program.cs`). If this value were accidentally committed to an `appsettings.json` or `.env` file, it would be a critical exposure. The lack of any secrets-management guardrails makes this risk higher. --- ## 5. Configuration Validation Assessment **Rating: Not implemented — critical gap.** There is zero startup validation. The application uses null-forgiving operators (`!`) at every configuration access point but provides no mechanism to fail fast at startup if required values are missing. Consequences: - If `AZURE_OPENAI_ENDPOINT` is missing or malformed, a `UriFormatException` is thrown at the point the `AzureOpenAIClient` singleton is first resolved — which may be mid-request, not at startup. - If `CosmosDb_ConnectionString` is missing, `new CosmosClient(null)` will throw an `ArgumentNullException` when the singleton is constructed, but this happens lazily and without a clear configuration-related error message. - If `CosmosDb_Database` or `CosmosDb_ProductContainer` are missing, the stored string fields will hold `null` despite the `!` operator, and the CosmosDB operation will fail at query time with a confusing error. ASP.NET Core 8 provides `ValidateDataAnnotations()` and `ValidateOnStart()` precisely for this scenario. Neither is used. --- ## 6. Environment Awareness Assessment **Rating: Minimal — single-environment configuration.** The project reads `ASPNETCORE_ENVIRONMENT` correctly (standard ASP.NET Core behavior), but there is only one `launchSettings.json` profile (`http`, setting `Development`) and only one `appsettings.json` file. No environment-specific behavior is configured. Specific concerns: - **Swagger is unconditionally enabled.** Lines 86-89 of `Program.cs` have the environment guard (`if (app.Environment.IsDevelopment())`) commented out. Swagger is enabled in all environments including production. - **CORS is `AllowAll` with no override.** The `AllowAll` policy (`AllowAnyOrigin`, `AllowAnyHeader`, `AllowAnyMethod`) is hardcoded and applied unconditionally. There is no environment-specific restriction. In production, this policy allows any origin to call the API. - **No Staging environment configuration** — the application has no documented path for a pre-production environment. --- ## 7. Findings | Severity | ID | Title | File | |---|---|---|---| | 🔴 Critical | ACFG-VALID-001 | No startup validation — missing config causes runtime failures | `src/ChatAPI/Program.cs` | | 🟡 Notable | ACFG-OPTIONS-001 | Raw `IConfiguration` injection in service classes instead of typed options | `src/ChatAPI/Data/ProductData.cs`, `ChatHistoryData.cs`, `GenerateProductInfo.cs` | | 🟡 Notable | ACFG-OPTIONS-002 | No typed options classes or `IOptions` used anywhere in the project | `src/ChatAPI/Program.cs` | | 🟡 Notable | ACFG-OPTIONS-003 | Direct `builder.Configuration["Key"]!` at service registration in `Program.cs` | `src/ChatAPI/Program.cs` | | 🟡 Notable | ACFG-SECRET-001 | No Azure Key Vault integration in the configuration pipeline | `src/ChatAPI/Program.cs` | | 🟡 Notable | ACFG-SECRET-002 | No `dotnet user-secrets` configured for local development | `src/ChatAPI/ChatAPI.csproj` | | 🟡 Notable | ACFG-VALID-002 | No `ValidateDataAnnotations()` or `ValidateOnStart()` for any options | `src/ChatAPI/Program.cs` | | 🟡 Notable | ACFG-ENV-001 | Swagger unconditionally enabled — environment guard is commented out | `src/ChatAPI/Program.cs` | | 🟡 Notable | ACFG-CORS-001 | `AllowAll` CORS policy hardcoded with no environment-specific override | `src/ChatAPI/Program.cs` | | 🟢 Minor | ACFG-STRUCT-001 | No `appsettings.Development.json` or `appsettings.Production.json` | `src/ChatAPI/` | | 🟢 Minor | ACFG-STRUCT-002 | Required configuration keys undocumented — absent from `appsettings.json` | `src/ChatAPI/appsettings.json` | | 🟢 Minor | ACFG-ENV-002 | `launchSettings.json` has only one profile — no HTTPS or Staging profile | `src/ChatAPI/Properties/launchSettings.json` | | ℹ️ Info | ACFG-POSIT-001 | No secrets committed to source control — `appsettings.json` is clean | `src/ChatAPI/appsettings.json` | ### Finding Details #### ACFG-VALID-001 🔴 Critical — No startup validation All ten configuration keys are consumed with `!` null-forgiving operators. If any key is missing in a deployment, the application will start successfully (returning HTTP 200 on health probes), then fail with `NullReferenceException`, `ArgumentNullException`, or `UriFormatException` at the first request that reaches the affected code path. This makes misconfigured deployments difficult to detect and diagnose. **Recommendation:** Introduce typed options classes and call `ValidateOnStart()` so the application refuses to start rather than silently failing mid-request. See §8 for a code example. --- #### ACFG-OPTIONS-001 🟡 Notable — Raw `IConfiguration` in service constructors `ProductData`, `ChatHistoryData`, and `GenerateProductInfo` all accept `IConfiguration` as a constructor parameter and call `config["CosmosDb_Database"]!` directly. This pattern couples service classes to the configuration system, makes the required configuration undiscoverable from the service contract, and bypasses all validation. **Recommendation:** Create a `CosmosDbOptions` class, register it with `services.Configure(config.GetSection("CosmosDb"))`, and inject `IOptions` instead of `IConfiguration`. --- #### ACFG-OPTIONS-002 🟡 Notable — No `IOptions` anywhere The entire project uses raw `IConfiguration`. There are no options classes defined in the codebase. **Recommendation:** Define options classes for the logical groups: `CosmosDbOptions`, `AzureOpenAIOptions`, `AzureSearchOptions`. Register with `services.Configure()`. --- #### ACFG-OPTIONS-003 🟡 Notable — Direct config access at service registration `Program.cs` lines 23, 28, 45, 46, 49-51, and 67 use `builder.Configuration["Key"]!` as lambda captures inside `AddSingleton(serviceProvider => ...)` factories. This pattern evaluates configuration at registration time and does not participate in `IOptions` change-notification or validation pipelines. **Recommendation:** Move to typed options with `IOptions` injection inside the factory lambdas, or validate the values eagerly at startup using `builder.Configuration.GetSection("Section").Get()` with null/empty checks before the application builds. --- #### ACFG-SECRET-001 🟡 Notable — No Azure Key Vault integration The configuration pipeline (`Program.cs`) does not call `AddAzureKeyVault()`. For a production deployment handling `CosmosDb_ConnectionString` and multiple service endpoints, Key Vault is the expected Azure-native secrets provider. Without it, all secrets must be delivered as environment variables or container secrets, which is manageable but misses audit trails, rotation support, and access control that Key Vault provides. **Recommendation:** Add `builder.Configuration.AddAzureKeyVault(new Uri(vaultUri), new DefaultAzureCredential())` to the configuration pipeline. Alternatively, document explicitly that Azure Container Apps secrets / environment variable injection is the chosen approach. --- #### ACFG-SECRET-002 🟡 Notable — No user-secrets for local development The `.csproj` has no ``. Developers must configure all ten environment variables locally to run the application. There is no documented process for this and no `.env.example` file. **Recommendation:** Add `` to the `.csproj`, run `dotnet user-secrets set` for each key, and document the setup process in the README. Alternatively, an `.env.example` file listing all required keys (with placeholder values) would significantly lower the developer-experience barrier. --- #### ACFG-VALID-002 🟡 Notable — No `ValidateDataAnnotations()` or `ValidateOnStart()` Even if typed options are adopted, validation must be explicitly enabled. `services.Configure()` alone does not validate. **Recommendation:** Chain `.ValidateDataAnnotations().ValidateOnStart()` when registering each options class. --- #### ACFG-ENV-001 🟡 Notable — Swagger unconditionally enabled Lines 85-89 of `Program.cs` show the environment guard for Swagger was intentionally commented out: ```csharp //if (app.Environment.IsDevelopment()) //{ app.UseSwagger(); app.UseSwaggerUI(); //} ``` This exposes the full API schema and Swagger UI in all environments, including production. **Recommendation:** Restore the `IsDevelopment()` guard, or introduce an explicit configuration flag (`Swagger:Enabled`) with a `false` default that can be overridden in `appsettings.Development.json`. --- #### ACFG-CORS-001 🟡 Notable — `AllowAll` CORS hardcoded `Program.cs` (lines 71-77) registers and unconditionally applies a `AllowAnyOrigin` / `AllowAnyHeader` / `AllowAnyMethod` CORS policy. There is no environment-specific override. **Recommendation:** Define CORS allowed origins in configuration (e.g., `Cors:AllowedOrigins`) with an environment-specific value. In production this should be the known frontend origin(s). `AllowAll` should only apply to local development. --- #### ACFG-STRUCT-001 🟢 Minor — No environment-specific appsettings files Only `appsettings.json` exists. There is no `appsettings.Development.json` for local development overrides (e.g., verbose logging, mock services) and no `appsettings.Production.json` for production hardening (e.g., stricter log levels, disabled Swagger, restricted CORS). **Recommendation:** Add at minimum `appsettings.Development.json` with development-specific log levels and Swagger enabled, and `appsettings.Production.json` that disables Swagger and restricts CORS. --- #### ACFG-STRUCT-002 🟢 Minor — Required config keys undocumented in `appsettings.json` The ten required configuration keys are entirely absent from `appsettings.json`. A developer cloning the repository has no discovery path without reading `Program.cs` and all service constructors. **Recommendation:** Add placeholder entries to `appsettings.json` (e.g., `"AZURE_OPENAI_ENDPOINT": ""`) so the configuration contract is self-documenting. When typed options are adopted, the options class properties serve this purpose automatically. --- #### ACFG-ENV-002 🟢 Minor — Single `launchSettings.json` profile Only an `http` profile exists. There is no HTTPS profile and no Staging profile. **Recommendation:** Add an `https` profile as a standard local development configuration. This is low priority but aligns with ASP.NET Core scaffolding defaults. --- #### ACFG-POSIT-001 ℹ️ Info — No secrets in source control `appsettings.json` contains only logging and host settings. No connection strings, API keys, or credentials are committed to source control. `DefaultAzureCredential` is used correctly for identity-based service access (Azure OpenAI, Azure AI Search). This is a positive finding. --- ## 8. Recommended Improvements | Finding | Recommended Action | Priority | |---|---|---| | ACFG-VALID-001 | Introduce typed options + `ValidateOnStart()` to fail fast on missing config | High | | ACFG-OPTIONS-001 | Create `CosmosDbOptions`, remove `IConfiguration` from service constructors | High | | ACFG-OPTIONS-002 | Create `AzureOpenAIOptions` and `AzureSearchOptions`, use `IOptions` | High | | ACFG-ENV-001 | Restore Swagger environment guard or add a config flag | High | | ACFG-CORS-001 | Move CORS origins to configuration with environment-specific defaults | High | | ACFG-OPTIONS-003 | Replace direct config access in `Program.cs` lambdas with typed options | Medium | | ACFG-SECRET-001 | Add Key Vault integration or explicitly document environment variable contract | Medium | | ACFG-SECRET-002 | Add `` to `.csproj` and document local setup | Medium | | ACFG-VALID-002 | Chain `ValidateDataAnnotations().ValidateOnStart()` for all options | Medium | | ACFG-STRUCT-001 | Add `appsettings.Development.json` and `appsettings.Production.json` | Low | | ACFG-STRUCT-002 | Add placeholder config keys to `appsettings.json` as documentation | Low | | ACFG-ENV-002 | Add HTTPS profile to `launchSettings.json` | Low | ### Typed Options Pattern — Example The following illustrates the recommended refactoring for CosmosDB configuration: **Options class:** ```csharp // src/ChatAPI/Options/CosmosDbOptions.cs using System.ComponentModel.DataAnnotations; public sealed class CosmosDbOptions { [Required] public string ConnectionString { get; set; } = string.Empty; [Required] public string Database { get; set; } = string.Empty; [Required] public string ProductContainer { get; set; } = string.Empty; [Required] public string ChatContainer { get; set; } = string.Empty; } ``` **Registration in `Program.cs`:** ```csharp builder.Services .AddOptions() .Bind(builder.Configuration.GetSection("CosmosDb")) .ValidateDataAnnotations() .ValidateOnStart(); builder.Services.AddSingleton(sp => { var opts = sp.GetRequiredService>().Value; return new CosmosClient(opts.ConnectionString); }); ``` **`appsettings.json` (documented placeholders):** ```json { "CosmosDb": { "ConnectionString": "", "Database": "", "ProductContainer": "", "ChatContainer": "" } } ``` **Service constructor (removes `IConfiguration` dependency):** ```csharp public sealed class ProductData(CosmosClient cosmosClient, ILogger logger, IOptions options) { private readonly string _databaseName = options.Value.Database; private readonly string _containerName = options.Value.ProductContainer; // ... } ``` --- ## Footer > This review is based on static analysis of source files as of 2026-03-21. No build was executed. Findings reflect the code state at audit time and do not represent runtime behavior. > > Generated by: `api-config-steward`