Now let's look at how to design a secure Azure application, although many of the points raised here apply to application design in general.

Pair - or peer - programming, where you write your code in teams of two, has been shown to improve code quality and learning within a development team. While this is not always practical, and not to everyone's liking, a less human-resource-hungry alternative is having regular code reviews, ideally before checking into source control, say at the end of an agile sprint. The more eyeballs on the code, the more likely performance and security issues will be detected.

As well as human code reviews, there are a myriad of tools that can analyze your code, highlighting potential security vulnerabilities. 

Validate all inputs to your application, as this is the first line of defense against injection-type attacks. This is a good rule of thumb for all software development, not just from a security perspective, but also to keep your data clean and meaningful. It is much easier to validate data at the point of entry than clean or parse it down the track. Try and make the user choose input from sets of options, than using free text fields. Always validate email and web addresses as being in the correct format, and not containing non-printing characters.

Verify your application's outputs, also known as escaping or output encoding. This means making sure that data is treated as data, and not misinterpreted, excuse the pun, as input relative to script, a script interpreter's parser. This is essentially guarding against another form of injection attack. An example of this might be someone uploading a file - like CSV orders - to your website, that has an executable script embedded in it. If the file is to be displayed, that is, processed and the output sent back to the browser, this is where the embedded script will be executed if the file's content hasn't been escaped. This type of attack is also known as cross-site scripting.

Use parameterized queries or stored procedures in place of dynamic SQL constructed within your application. While building dynamic SQL statements in your application might appear to be a shortcut compared to a complex if-then-else type scenario, and was in vogue many years ago, it can have potentially disastrous consequences. Without very good validation, someone can enter SQL script as input that will be incorporated into your dynamic SQL, that will be executed with completely unintended consequences. It's just not worth the risk.

Remove standard server headers. By default, all web servers emit in their headers sent to browsers what type of web server it is. For example, server is Microsoft IIS version 8, powered by ASP.NET. This information could be useful to someone wanting to attack your website. Removing that information is easy and won't impact functionality. In your Web.config file, under <system.webServer> and <security>, set <requestFiltering removeServerHeader="true" />. Also, under the custom headers node in <httpProtocol>, create a remove node with name="X-Powered-By". Under <system.web>, create a node for httpRuntime with the value enableVersionHeader="false", to remove the ASP.NET version.

Don't develop or test against production data, even if it is in a development or test environment. There is little point going through all the effort of securing your production data, only to have it exposed in insecure and untested scenarios.

Implement a strong password policy that forces users to create complex passwords. While this has been a source of much angst amongst users, research has shown that long passwords are just as good as complex ones. Making users have phrases with upper and lower case, as opposed to just words, would make life easier and more secure.

Check file uploads for viruses and malicious content. This is another form of input validation. It's hard enough to stop employees clicking on phishing emails, without opening the door to hackers by letting them into your inner sanctum with a simple file upload.

Don't cache sensitive data in the browser, like personal or payment data, that could be maliciously accessed by accessing the browsers cache or hitting the back button. And be careful how you use URL query parameters, if you have to use them at all. That is, don't display unencrypted data like record IDs, and don't put connection strings, keys, or other critical configuration data into apps or config files. Use app settings to store this type of information. App settings are encrypted, and the app servers will make the information available to your app only when required.

Once the application has been developed, you need to verify that it is secure. To do this, find and fix vulnerabilities in your application dependencies by scanning your application and its dependent libraries to identify any known vulnerable components. Vulnerability scanning, powered by Tinfoil Security, is available for Azure at service web apps.

Test your application in an operating state. That will help you to find security vulnerabilities such as memory corruption, insecure server configuration, cross-site scripting, user privilege issues, SQL injection, and other critical security concerns.

Fuzz testing is testing your applications robustness. How does the application perform when deliberately crashed? Does it expose security flaws?

Conduct attack surface review after any changes, to make sure no new attack vectors have been introduced. Attack Surface Analyzer from Microsoft can scan your application for vulnerabilities.

Perform security penetration testing on deployment, and monitor for open ports, endpoints, and attacks.

Secure DevOps Kit for Azure contains SVTs for multiple services of the Azure platform. You run these SVTs periodically to ensure that your Azure subscription, and the different resources that comprise your application, are in a secure state. You can also automate these tests by using the continuous integration/continuous deployment (CI/CD) extensions feature of AzSK, which makes SVTs available as a Visual Studio extension.

Applications are rarely static, and will be amended and modified throughout their lifecycle. You must have security verification procedures in place to monitor apps on an ongoing basis.