Application security for the startup founder
There are quite a few news stories nowadays about cybercrime and its effects. It seems like every week brings news of a new high profile data breach exposing millions of users’ data. Security is something that’s hard to nail down for even large and technically proficient organisations. It’s a topic that’s difficult and critically important to an organisation’s success. But what about startups? How does a startup know that it’s taking reasonable precautions to ensure that it’s protecting its users and itself from hostile actors?
Before working with startups, helping them to create their prototypes and MVPs, I worked in the cybersecurity industry. One of the common complaints of security professionals is how organisations, particularly startups, don’t take the time and the energy to implement even basic security practices in their applications. Too often, startups see security as an impediment to getting their product to market. The problem with that attitude is that it can often be robbing Peter to pay Paul. When a startup scales up, those vulnerabilities often become a major liability that are much harder to fix when their systems are larger and more complex. A more mature organisation has data stores that are juicier targets for criminals. Just because you haven’t had a breach when you’re small, doesn’t mean you won’t have one in the future.
But the goal of this article is not to scare you about security, but to make founders think about how they can implement some basic security practices in their applications without impacting their development velocity. This isn’t meant to be an exhaustive list, but will hopefully get you thinking about how to implement the basics and ask the right questions to create a culture that’s mindful of security while its moving fast and breaking things.
Sanitise, sanitise and sanitise again
Not sanitising user generated data is one of the biggest mistakes that application developers make when building out systems. Anywhere users enter text is a place where malicious code can be inserted into your app. Whether it’s the adventures of Bobby Tables or the lengths that some will use to get out of a speeding ticket, a whole host of attacks can be stopped by simply making sure you sanitise every user input. This is something that even large organisations miss.
So what does sanitise mean? It simply means that user input is checked for any special characters that might allow user-entered code to be executed.
The good news is that a lot of libraries have sanitisation baked in, but that should not mean you can take it for granted. It pays to have inputs sanitised in the front end, but also when data comes into the API. The idea is to make sure that, by the time the information reaches your database, it is treated as text and not code that can potentially be executed. It’s best to assume that all user input is a potential attack.
Questions to ask
- Does library X sanitise untrusted content?
- What are we doing to prevent injection attacks and cross site scripting(XSS)?
Update and patch
We’ve all been there as developers, you dread seeing that a new version of a library or tool you’re using has a new version. Will it break your build? Can it wait until after your ship deadline?
But updating your software is a simple way of staying safer as an organisation. Library developers are usually trying to patch vulnerabilities whenever they are discovered. Making sure that you update your project’s dependencies as soon as possible ensures that you’re not going to fall victim to bad actors trying to take advantage of the vulnerability before it is widely patched. Sometimes updating can be a painful process if it introduces bugs or breaks a build right before a deadline. But delaying updates often leads to much more painful bugs than small, frequent updates.
Luckily, package managers like NPM now have an audit feature that will scan your project and attempt to fix them.
Questions to ask
- When was the last time we checked for vulnerabilities in our dependencies?
- What’s our schedule and budget for making sure our dependencies and tools are up to date?
Check your config
When setting up web application infrastructure(servers, databases, etc.) it’s important to make sure it is configured in a secure manner. It’s best to use the principle of least privilege. That is, users and application components should only have access to data that they need to access.
A lot of databases have restrictive default configurations for this purpose, but that does not mean that you should assume this is so.
Sometimes, the hassle of granting permissions can create the temptation to over expose-data. This can lead to embarrassing public data exposures, like leaking 93 million Mexican voter records.
Questions to ask
- Who has access to this data?
- Is our permission system role based?
- What parts of our application are exposed to the internet?
Want to know more?
This is not an exhaustive list of best practices to keep your organisation safe, but will go a long way to making yourself a harder target for bad actors as you build your product and your business. Of course application security is not the only type of security your organisation should be aware of, but it’s one that is so often overlooked in the race to market.
Security is a mindset, one that everyone in the organisation needs to adopt. Security doesn’t have to slow your development process down or require an expensive third party solution. By keeping the basics in mind, you can scale more confidently and reduce the risk of an expensive and embarrassing breach.
Developers wanting to learn more about application security can find good quality information at the OWASP Foundation. Their Top 10 is a great source of information for those looking for more detail about popular attack methods for applications.
Founders wanting to have a better understanding of security more broadly should checkout this great general security training from Pagerduty.
Joe Dragovich is an engineer at Kanso in the UK.
Founder looking for a team to create a digital product? Because Kanso can help.
Developer, designer or consultant looking for a new team? Because Kanso are hiring.
