Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Harden Azure Key Vault trusted endpoint matching

Open
  • Is something wrong?
#4,802 1 comment 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 2 days

@apoorvdeshmukh is already working on this.

Since Oct 13, 2026.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
azure, csharp
Domain
backend, security

Research direction

Start by locating SqlColumnEncryptionAzureKeyVaultProvider and reading its trusted-endpoint validation and constructor behavior, then inspect the related tests. Add coverage for the listed DNS, scheme, port, normalization, and input-mutation cases; done means endpoint validation follows the requested structured rules while preserving the described compatibility path.

Written by the indexing model from the issue text.

Description

Area\AKV Provider
Is your feature request related to a problem? Please describe.

SqlColumnEncryptionAzureKeyVaultProvider validates an Azure Key Vault key URI by checking whether Uri.Host ends with one of its trusted endpoint strings. Raw suffix matching does not require a DNS-label boundary, so a hostname can match a trusted suffix without being that domain or one of its subdomains.

The trusted-endpoint representation also does not express whether an entry is an exact host, a DNS suffix, or a complete origin. This makes it difficult to apply clear scheme and port rules to application-supplied endpoints while preserving compatibility with custom Azure environments and development endpoints.

Describe the solution you'd like

Harden and clarify trusted endpoint validation:

  • Match built-in domain suffixes only when the host is exactly the suffix or ends with "." + suffix, using ordinal case-insensitive comparison.
  • Normalize DNS hosts consistently, including IDN and terminal-dot handling.
  • Require HTTPS for built-in Azure Key Vault and Managed HSM endpoints.
  • Validate and normalize application-supplied trusted endpoints when the provider is constructed.
  • Provide structured semantics for custom endpoints, distinguishing exact origins from entries that intentionally include DNS subdomains.
  • Defensively copy trusted endpoint collections so validation policy cannot be changed by mutating the constructor input.
  • Preserve reasonable compatibility for existing custom endpoints, with diagnostics and an explicit migration path for ambiguous legacy entries.

Add tests covering:

  • Valid exact hosts and subdomains.
  • Lookalike suffixes that do not share a DNS-label boundary.
  • Hosts that append another DNS suffix after a trusted name.
  • Mixed-case, IDN, and terminal-dot hostnames.
  • HTTP, HTTPS, default ports, and explicit custom ports.
  • Mutation of the input trusted-endpoint array after construction.
Describe alternatives you've considered
  • Keep raw EndsWith matching. This retains ambiguous behavior and does not accurately model DNS domain membership.
  • Require exact host matching for every entry. This would not work for the built-in Azure Key Vault domains, where each vault has its own subdomain.
  • Immediately reject every legacy custom endpoint format. This would provide simpler rules but could unnecessarily disrupt applications using private clouds, proxies, or development services. A compatibility-conscious migration to structured endpoint rules is preferable.
Additional context

The current built-in list covers Azure Key Vault and Managed HSM domains in public and sovereign clouds. DNS-label-boundary matching should preserve valid hostnames beneath those domains while making the allowlist behavior precise.

Dominant language
C#
Stars
996
Forks
348
Avg merge
6d 3h
Merged PRs (30d)
58

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dotnet/SqlClient

All issues in dotnet/SqlClient

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.