Skip to content

Securely Handling Secrets in HTTP Files with Visual Studio 2022

Photo by Magali Guimarães

Visual Studio has received a great improvement into .http file handling. Version 17.8 Preview 1 includes a support for secret handling, so you don’t need to add comments about replacing tokens or access keys into .http files anymore. From now on you can use ASP.NET Core user secrets, Windows DPAPI or even Azure Key Vault to store your API secrets. I think that Azure Key Vault is the most interesting, so I will dive deeper into that option.

.HTTP Files

If you are not familiar with HTTP files, I will give you a brief intro. HTTP files in Visual Studio simplify the testing and interaction with Web APIs directly within the IDE. HTTP files are commonly used during web application development and debugging. They provide a structured way to create and send HTTP requests, receive responses, and observe the outcomes, eliminating the need for external tools like Postman or Curl. They help keep developer inside IDE, which removes extra friction of changing the tools and context switching.

Now in latest preview of Visual Studio, you can create httpenv.json and httpenv.json.user files, that can store secrets required to do HTTP calls in .http files.

Azure Key Vault

Azure Key Vault is a key management solution in Azure, primarily designed for securely managing secrets and other artifacts like certificates. Azure Key Vault is the recommended solution to share secrets among different users and apps and it’s now also supported in the HTTP environment file. To use a value from Azure Key Vault, you will need to define a new variable and add the necessary metadata to access that secret securely. The recommended way to store the Key Vault information is to use user specific setting files (httpenv.json.user). You should not store these files into version control, but you can provide a template through VC or documentation.

Call Azure Key Vault From .HTTP Files

To use the Azure Key Vault (AKV later) from .http files, we need to first setup environment file, that defines what kind of environments our .http files are supporting. This file should be in the same folder as the HTTP file, or a folder above it. For simplicity we will add only one environment, that is called dev and add example value called Api_HostAddress into it. We can use this very cool website called webhook.site to test our .http file requests.

{
  "dev": {
    "Api_HostAddress": "webhook.site"
  }
}

OK so that is the content of httpenv.json file. Remember to store it in the same folder as the .http file or folder above it. In summary the JSON file contains one environment called local, that has one variable called Api_HostAddress. We could create multiple environments and change them by opening .http file in Visual Studio and using dropdown at top right corner of Visual Studio to change the environment. For simplicity, let’s stick with one environment.

Next we need to create the user specific environment file (httpenv.json.user), that will extend this environment file by adding secret into it. This file should be within httpenv.json file, so Visual Studio will automatically wrap it under httpenv.json file.

httpenv.json.user is under httpenv.json in Solution Explorer
{
    "dev": {
      "fromKeyVaultSecret": {
      "provider": "AzureKeyVault",
      "keyVaultName": "(name of your key vault)",
      "secretName": "(your secret name)",
      "resourceId": "/subscriptions/(subscription id)/resourceGroups/(resource group name)"
    }
  }
}

In this sample we have variable called fromKeyVaultSecret, that will receive it value from AKV. We need to put the value under environment like in httpenv.json. You can find the rest of values for AKV settings easily from Key Vaults Azure Portal properties page. The Visual Studio will use your sign in to access the AKV, so you need to be signed into Visual Studio with Azure account that has the access to AKV.

To test this out we can create .http file that has following content

@Api_HostAddress = webhook.site

GET https://{{Api_HostAddress}}/03e4e108-2057-4699-b9e3-168bfe1633ca
X-AUTHORIZATION-SECRET: {{fromKeyVaultSecret}}

In this example we have variable called Api_HostAddress where we store the base address of our test API and use it in every tests (value is overridden by environment json). Next we will have test that does a GET call into unique GUID adress (by visiting webhook.site website you can get your own unique GUID to test this out). The interesting part is at X-AUTHORIZATION-SECRET. For that we will use the AKV secret, that we have already defined in httpenv.json.user file. Now during execution the Visual Studio will fetch that value from Key Vault and send it as a header value. Here is what the result looks like at webhook.site. We can see, that there is x-authorization-secret sent with a value of 123456789 (value that I have stored in AKV)

HTTP request header has x-authorization-secret value from Key Vault

To learn more about using secrets in .http files, check out this Microsoft blog: https://devblogs.microsoft.com/visualstudio/safely-use-secrets-in-http-requests-in-visual-studio-2022/?wt.mc_id=WDIT-MVP-5000377

Summary

I like how Microsoft is improving .http files and bringing new features into them. Secret handling is one of the key points of API testing and you usually have to solve it somehow. With Azure Key Vault support we can easily integrate Key Vault into http files and use the protection it provides to avoid handling secret in our local machine. Great stuff!

Behind the Scene

To be honest I had lot of problems while writing this blog post. First problem was, that when I updated my work laptops Visual Studio into preview build, it completely broke the http files. I could not make any http requests from http files anymore and had to revert back to current version. Then I installed preview build into different machine where it also did not work, because I didn’t have .NET 7.0. I had 8.0 preview and 6.0, but this feature seems to be hard coded somehow into 7.0. After installing it I managed to get it working… kind of. Next problem was that Key Vault authorization did not work, even though every setting was correct. I could not solve this within the same day, but after shutting down computer for the night in next day everything worked without any issues… So I would recommend to wait the final release of Visual Studio before thinking about more serious usage of this feature.

Last issue was, that you need to refresh (close and open) http files every time you change environment files. I think this is going to be improved in near future, but as in current state you need to do lot of closing and opening http files to get settings working.