Security by design – common vulnerabilities found in web applications during security testing

Some websites use security through obscurity as their main means of protection. This methodology relies on making the vulnerabilities hard to obtain by not making the system’s design known to the general public. As anyone knows, a secret is never a secret for very long.

This is bad practice and careless. Concealing a vulnerability will only delay an attacker and not pass any form of security testing. The right approach is to have security as part of the design process of a system.

Some people are not that careful, like Bond’s most recent foe:

Q: This is omega site. Best encrypted level he has. Looks like obfuscated code to conceal its true purpose. Security through obscurity.”


Security must be by design. It is more cost effective to have security as part of the design process than to retro-fit into an existing solution.

What can you do to protect your system?

A few simple rules will take you a long way.

  • SSL – always have your login pages and pages with sensitive information secured with SSL. There is a growing bias towards putting the entire site under HTTPS as any performance hits and CDN/browser “cacheability” problems are a thing of the past.

  • Use well known libraries and patterns for user authentication. In .NET if you are building a small site use the standard forms authentication. If building an enterprise solution, use an STS such as AD FS or Azure ACS.

  • Protect your online forms against spam and “open-relay” attacks using captchas or honey traps.

  • Prevent SQL injection attacks by cleansing your input.

  • Avoid XSS and CSRF attacks.

  • Increase the security levels from the defaults, e.g. change the default password hashing algorithm in .NET to SHA512.

  • Do not disclose any information about your physical environment’s ecosystem, e.g. remove server headers and OS information. Implementing the OWASP (Open Web Application Security Project) guidelines will increase your solutions security. These guidelines should be followed from the projects inception to ensure you achieve a secure and robust solution.< This year’s release candidate Top 10 vulnerabilities document is a good place to start to understand what the most common vulnerabilities are and what we can do to protect ourselves against them. I’ll expand on these topics individually in following blog posts. References: