This tutorial shows how your code can securely store and access secure information. The most important point is you should never store passwords or other sensitive data in source code, and you shouldn't use production secrets in development and test mode.
The sample code is a simple WebJob console app and a ASP.NET MVC app that needs access to a database connection string password, Twilio, Google and SendGrid secure keys.
On premise settings and PHP is also mentioned.
The ASP.NET runtime merges the contents of the external file with the markup in <appSettings> element. The runtime ignores the file attribute if the specified file cannot be found.
Security - Do not add your secrets .config file to your project or check it into source control. By default, Visual Studio sets the Build Action to Content, which means the file is deployed. For more information see Why don't all of the files in my project folder get deployed? Although you can use any extension for the secrets .config file, it's best to keep it .config, as config files are not served by IIS. Notice also that the AppSettingsSecrets.config file is two directory levels up from the web.config file, so it's completely out of the solution directory. By moving the file out of the solution directory, "git add *" won't add it to your repository.
Visual Studio creates new ASP.NET projects that use LocalDB. LocalDB was created specifically for the development environment. It doesn't require a password, therefore you don't need to do anything to prevent secrets from being checked into your source code. Some development teams use the full versions of SQL Server (or other DBMS) that require a password.
If you use the configSource attribute as shown above to move your connection strings to an external file, and have Visual Studio create a new web site, it won't be able to detect you are using a database, and you won't get the option of configuring the database when you publish to Azure from Visual Studio. If you are using the configSource attribute, you can use PowerShell to create and deploy your web site and database, or you can create the web site and the database in the portal before you publish. The New-AzureWebsitewithDB.ps1 script will create a new web site and database.
Security - Unlike the AppSettingsSecrets.config file, the external connection strings file must be in the same directory as the root web.config file, so you'll have to take precautions to ensure you don't check it into your source repository.
Security Warning on secrets file: A best practice is to not use production secrets in test and development. Using production passwords in test or development leaks those secrets.
The app.config file used by a console app doesn't support relative paths, but it does support absolute paths. You can use an absolute path to move your secrets out of your project directory. The following markup shows the secrets in the C:\secrets\AppSettingsSecrets.config file, and non sensitive data in the app.config file.
Go to https://portal.azure.com, and sign in with your Azure credentials.
Click Browse > Web Apps, then click the name of your web app.
Click All settings > Application settings.
The app settings and connection string values override the same settings in the web.config file. In our example, we did not deploy these settings to Azure, but if these keys were in the web.config file, the settings shown on the portal would take precedence.
$credPath = $PSScriptRoot + '\' + $Name + ".credential"
# $user just for debugging.
Security - Don't include passwords or other secrets in the PowerShell script, doing so defeats the purpose of using a PowerShell script to deploy sensitive data. The Get-Credential cmdlet provides a secure mechanism to obtain a password. Using a UI prompt can prevent leaking a password.
DB connection strings are handled similarly to app settings. If you deploy your web app from Visual Studio, the connection string will be configured for you. You can verify this in the portal. The recommended way to set the connection string is with PowerShell. For an example of a PowerShell script the creates a website and database and sets the connection string in the website, download New-AzureWebsitewithDB.ps1 from the Azure Script library.
Since the key-value pairs for both app settings and connection strings are stored in environment variables on Azure App Service, developers that use any web app frameworks (such as PHP) can easily retrieve these values. See Stefan Schackow's Windows Azure Web Sites: How Application Strings and Connection Strings Work blog post which shows a PHP snippet to read app settings and connection strings.
If you are deploying to on-premises web servers, you can help secure secrets by encrypting the configuration sections of configuration files. As an alternative, you can use the same approach recommended for Azure Websites: keep development settings in configuration files, and use environment variable values for production settings. In this case, however, you have to write application code for functionality that is automatic in Azure Websites: retrieve settings from environment variables and use those values in place of configuration file settings, or use configuration file settings when environment variables are not found.
For an example of a PowerShell script that creates a web app + database, sets the connection string + app settings, download New-AzureWebsitewithDB.ps1 from the Azure Script library.
Special thanks to Barry Dorrans ( @blowdart ) and Carlos Farre for reviewing.