Hiding Application Secrets

How do you secure your database username and password that appears in your connection string? Don't put it in your Web.config directly. Put it in a separate file (here called Web_deploy.config, and then reference it with the configSource attribute. This new file should NOT be added to your project and should NOT be added to your Git repository (put it in your .gitignore). As you can see to the right, it does not appear within the project.

But it is present in the directory. You'll have to manually share it with all developers on your team. Also note that this config file apparently must be placed in the same directory as your normal Web.config -- it cannot be moved to a different directory. Also note that you can't include anything inside the connectionStrings element; it must be empty. All entries go in the hidden config file.

This hidden config file has only the connectionStrings element, and it can contain any connection strings that you need.

If you try to deploy the project above using continuous deployment from your Git repository you'll find errors when the web app tries to connect to the database. It won't be able to find the Web_deploy.config file. So remove it. When merging into your master branch for deployment, edit the connectionStrings element so it looks like this.

Now there's no connection string at all. How can it find your database? The question becomes, “how can you get these same application secrets onto Azure?” Simple, add them to your Azure Web App.

What about other application secrets? If you use Google's reCaptcha you'll get 2 keys that you must use in order to use their API. Microsoft's SendGrid for sending emails requires a key. You might need to create an Admin account. Those examples are shown below. The Application settings tab in the App Service on the Azure Portal has a place to input key-value pairs for your application to query at runtime. Here's mine (appropriately grey'd out for security purposes):

You can access these key-value pairs with the following code. This one is for creating an admin user (in Startup.cs)

and this one initializes SendGrid to send confirmation emails after a user registers for an account (in IdentityConfig.cs)

This works great on Azure, but what about testing when you're deploying locally? Where does your local instance get these keys from? The answer is a separate file that is, again, NOT added to your Git repository or added to your Visual Studio project. This one goes outside your project folder (here my project is called standups)

and contains your secrets in an appSettings element.

How does MVC know to look in this file for application settings? You need to add a file attribute to the appSettings element in your main Web.config as shown here. This can be left in place when deploying on Azure.