A Seasoned Security Specialist Reviewed My Code. These 3 Lessons Proved to be Invaluable.

About security lessons that are not learned the hard way.

In my professional career, I quite often work on online applications that deal with the personal data of clients. Keeping this sensitive data — like bank account numbers or addresses — safe is a priority, that much goes without saying. Therefore, security has always been an important part of code reviews and pen tests are often a staple of the development process.

However, during a regular pen test, the security analysts are trying to get in from the outside. They are provided little knowledge about the architecture of the application and neither have access to the source code. As a result, a plethora of generic tests are run, whose ‘success’ ratio is filed in the final report.

Although these kinds of traditional pen tests may expose vulnerabilities, distilling any lasting lessons or root causes from them is often harder. And exactly that kind of deeper, more structural knowledge about security flaws is needed to make applications safer in the long term.

That’s why a company I worked at hired a security specialist with a refreshing point of view. Instead of standing outside trying to pick a lock, he saw it in half to inspect the quality from the inside.

This security specialist required full access to and an explanation of the source code. Because he had also worked as a software engineer, he could carefully read the code to sport patterns that may compromise security. After his analysis, he met up with our team to not only let us fix the errors per se, but, more importantly, teach us how we could prevent these kinds of errors in the future. This proved to be very insightful. I’ve summarized the most important lessons below.

1. Follow the spec

Secure apps follow the well-trodden path. Security best practices and specs exist because they are battle-tested. They passed the test of time. Therefore, when you are implementing common functionality — like granting third parties access to your API — look for common solutions — like oauth2. Nearly all security questions have been answered appropriately. So don’t reinvent the wheel, but look for a proven solution/spec and follow it.

It’s even more preferable to not follow the spec yourself, but to instead use well-maintained dependencies. If you implement an oauth2 flow all by yourself, chances are you will misinterpret or deviate from the specification at some point.

Furthermore, the specification isn’t set in stone, meaning you will have to keep updating your code to match the spec. Using well-maintained and tested dependencies reduces the risk of errors whilst minimizing the need for maintenance.

2. Make security an integral part of dependency selection

A lot of security vulnerabilities don’t stem from your own code, but from the dependencies you use. When selecting dependencies, ease of use and performance are often the main criteria. But how do you make sure that the vast capabilities of your chosen dependency aren’t accompanied by equally vast security risks?

For starters, it’s a good idea to check if the dependency itself highlights security as a feature. If the safety of the package isn’t heralded as an asset, it probably isn’t.

Secondly, the track record of the dependency should be checked. Did the dependency have any noteworthy security breaches in the past? And, if so, how quickly and effectively were the issues addressed? If some problems existed in the past that weren’t solved adequately, you should be wary to include the dependency in your project.

Lastly, you should check if the dependency is widely used and actively maintained. This increases the chances of problems being found and addressed prematurely.

3. Isolate insecure operations

Some, often necessary, processes within web applications are inherently insecure. A good example is the handling/parsing of uploaded files from the client. Files may contain malicious software, be malformed or trigger an unwanted redirect when parsed.

Making file uploads and file parsing secure is hard. So you want to give yourself some leeway in case things do go awry. A great way to do this is by isolating the insecure operation. So, for example, you could handle uploaded files in a separate container/cloud function that doesn’t have access to the rest of your server. In that case, when a fire does light up, it doesn’t spread that easily. So whenever you can, isolate dangerous operations.

That’s it: 3 structural security lessons from an expert in the field. Did you enjoy the article? Be sure the follow me for more interesting content!

More content at PlainEnglish.io. Sign up for our free weekly newsletter. Follow us on Twitter and LinkedIn. Join our community Discord.