First 5 Tips for Building Secure (Web) Apps

Lately, everybody and their dog has gotten hacked. New vulnerabilities are found every day, and web apps have a very wide surface area that can be targeted by attackers. How do I stay secure? We will give you a starting point in this post.

You can follow people like Troy Hunt or take a look at his Have I Been Pwned site to see how many security breaches occur on a daily basis. Or, take a look at the list of vulnerabilities in Windows 10, and how every Patch Tuesday brings security fixes. A few weeks ago it turned out that sudo was also very easy to exploit. This will give you an idea of how the security landscape moves at a blinding speed, and that security is a very serious matter.

The question is – how do I handle that? Where do I get started with my apps’ security? Here are my top five tips for starting with your application security, in a short little post.

Tip 1 – Start Educating Yourself

The very first thing to go to is the OWASP (short for Open Web Application Security Project™) Top 10 Vulnerabilities project. A direct link to the latest version of the report at the time of writing is here.

If you work for a large company, it’s likely that someone has already thought about security. If nothing else, your own company’s assets should be protected and monitored and there are people who do this. Talk to them. They can point you in the right direction, perhaps offer some policies and best practices, or further courses.

Even if you are a freelancer or work in a small dev shop, there are many online courses you can watch or take. It’s important, and it can even be interesting. In any case, it will broaden your horizons.

Tip 2 – Develop With Security in Mind

When you implement a form or an API/service endpoint, think not only of how you would use it, but also how you could abuse it. Some of the main attack vectors in a web app are where user input comes in – be that as actual input from a <form>, or by making requests for data. Authentication, sanitization and authorization should be the first things that happen to the request before it even touches the database or business logic.

Developing with security in mind also means that you should consider the way the app will handle its security from the get-go. This includes authentication and authorization services, access control, whitelisting, communication between projects in the same solution (or from other solutions/vendors), and so on. Do not leave that for later, it must be clear from early on, so that all elements of your app handle it properly.

Make no mistake, this also applies to intranet apps that are not available to the general public, not just to your online stores.

Tip 3 – Monitor CVE Databases

A quick online search for something like “<Vendor Name> <Product Name> vulnerability” will give you a list and links to those databases, so it won’t take much of your time.

Occasionally, you can peek at vulnerability databases to see if there is anything that affects you. Some even allow you to create feeds and monitor certain categories (for example, nvd.nist.gov and cvedetails.com). Here’s also a vendor list for Telerik products.

Tip 4 – Use the Latest Versions of Packages You Depend on

I mentioned it above, but I will re-iterate – vulnerabilities and issues are found all the time, everywhere. The general way they are fixed is “in the latest version” of the corresponding package/tool.

So, try to keep up to date with the software your app uses. This can be frameworks (if you’re still on .NET 3.5 or 4.0 – I’m looking at you), generic packages (like fetching jQuery or Newtonsoft.Json from NuGet) or other software from vendors like us.

Being updated usually will also provide you with new features, other fixes and improvements, not just better security.

Moreover, the more often you update, the easier it will be. Vendors generally strive to avoid breaking changes (I know we do), and even when they happen, they happen rather rarely. Hitting one change every once in a while is better than hitting 5 at once when you finally update from something written in 2011 when you also may have to consider other paradigm shifts in the frameworks and technologies.

Here’s also our guide on upgrading your Telerik UI for ASP.NET AJAX controls, which also shows how to monitor for changes and the tools we provide for that, so it’s easy for you to keep your Telerik bits updated.

Update: An example of a security enhancement in the latest version is the AllowedCustomMetaDataTypes appSettings key, which is discussed in the Allows JavaScriptSerializer Deserialization KB article and the R1 2020 (version 2020.1.114) release notes.

Tip 5 – Ask Your Vendors

This ties in with the previous point, but I wanted to keep it separate for a couple of reasons.

Reason 1: If the vendor does not know, this will at least make them think about the concept. Perhaps they should also adopt some security best practices into their SDLC, who knows. I, for one, don’t know if you would want to keep working with a vendor who does not care about security.

Reason 2: Sometimes it’s just easier to ask than to wade through online resources. The most common answer you’ll get is that “the latest version has no known vulnerabilities,” which should be another incentive for you to update to it.

A key thing in the previous paragraph is the word “known.” They say that what you don’t know can’t hurt you, but with security that’s not really the case. This is also why vulnerabilities are often found in older versions of software products – certain things, approaches or code that were considered OK at the time of their writing, are not good enough anymore, and information about that may be unearthed even years later.

For example, we just updated the information here to reflect new findings even though we fixed the original vulnerability two and a half years ago, and those new findings don’t affect the later versions. To reiterate the original advisory we sent back then (and what I have been saying in this post), the best solution is to upgrade to the latest version (at the time of your reading, not at the time of this writing), which contains even more security improvements.

Reason 3: What if you found a vulnerability in a vendor’s product that’s not listed online? Perhaps you found it while working with the product, or a security audit/penetration testing on your app brought it to light. In any case, you should reach out your vendor privately, because they are the only people who can fix it, but they can’t do that if they don’t know about it.

A common practice for handling such reports by software vendors is called “responsible disclosure” where information about a vulnerability will only be published after the vendor has released a fix for the problem. Usually, this happens in a new version, but that may vary depending on the distribution model of the product – for example, an OS or a massive end-to-end product will often ship patches (often for their latest version only), while smaller products (like NuGet packages or component vendors like us) usually release new versions.

What information becomes public is a matter of your own discretion, and there’s a fine line to walk between giving your fellow developers enough information to protect them, and providing too much so black hats or even script kiddies can exploit issues. My personal belief is that it should be known what the attack vector and its implications are so developers can understand the situation and determine if they are affected, but the exact exploit details should not be public.

What if you found a vulnerability in a Telerik product?  Follow our Vulnerability Disclosure Policy page.

In Summary

Communication about security is a two-way street and by participating you help improve the world for everyone. If you have something to add (even “small” things like online courses or articles you liked), put it in the comments below and help your fellow devs build secure apps.