Crashtest Security Blog

Security Best Practices for Start-ups

Sep 25, 2017 11:39:00 AM / by Janosch Maier

"Without Security you have no Business"

Security needs to be a number one priority for start-ups. Amazon CTO Werner Vogels stated on the Munich Founder Conference Bits & Pretzels why it is so important: "Without security, you have no business".


Statistics show alarming numbers regarding to security. For example, the Web Application Security Report 2016 shows that most websites are vulnerable most of the time. An open critical vulnerability takes more than 300 days on average to be fixed.

For start-ups with limited resources, resource planning is always a balancing act. Allocating resources for things like security, accounting, legal stuff or data privacy means that there is less time to focus on the important things like product development or sales. As a young company, we face exactly the same problems. As with all the topics, the founders need to have some knowledge about security. Here are some questions, founders need to be able to answer. Based on the answers, some best practices can already improve the security for a start-up a lot.

  • What are our important assets, you need to protect?
  • Who needs access to which data?
  • Which attack scenarios are likely to happen?


Security Baseline

Only if you know what you need to protect, you can take appropriate action. For a hardware start-up with a complex technology, the security aspect looks quite different as for a SaaS or e-commerce start-up. Knowing which people are involved in which processes is important to be able in limiting access. It is just the baseline to structure access to the data. And if you have some ideas of wat attackers want for you gives you good information about what may need protection against. Again, this heavily depends on what you need to protect.


Best Practices

For many SaaS start-ups the answers to the questions may look something like this:

  • We have some algorithm or data which we offer online to our customers. We do not want for somebody else to gain our private algorithm (or data) and our customer information.
  • Our tech-people need to know what our software is doing, our sales team needs to know the customers.
  • Attackers may try to hack our website to steal information from us or get access to our services (and then steal information).

As you probably cannot afford some expensive security coaching or audit, use the following best practices to increase your security as a very important first step.


Minimize Attack Surface Area

Everything available publicly may open an attack vector. Therefore try to limit the public endpoints and secure them properly. For a first step limit the access to all your servers by only allowing login with an SSH key.


Establish Secure Defaults

You may chose to give your users options. Wherever options relate to security, make sure that the defaults are the secure version. For example, you may provide webhooks for your users that are only secured by a hash value as authentication measure. Do not provide a webhook for everybody by default, but let your users generate them only if they need them.


Principle of Least Privilege

Try to be as restrictive as possible. Just imagine somebody managed to break into some part of the system. In this case the damage he can do should be as small as possible. Try to grant your services only the privileges they really need to do their work. For example do not use the root account of your database to connect your web application. Add an extra user for the application that has only read/write access on the tables that it really needs.


Principle of Defense in Depth

Even if one line of defence is good, more are better. For example do not only rely on users to login with username and password, but add a Two-Factor Authentication. Make sure, that users are always properly authenticated before granting access to sensitive information. This prevents anonymous attacks and raises the bar for an intruder.


Fail Securely

Programs will fail. Use exceptions in your code to make sure that your code does not allow an inconsistent state of your application. Check that security routines such as authentication are correctly passed before granting privileges. Think of the following code:



if not user.is_authenticated():






Now think of a problem in the fail method. If it does not work correctly, the show_content method is run. To increase the security it is sufficient to switch the statements. Now an error in the fail method has much less effect.



if user.is_authenticated():






Treat all Input as Evil (and Don't Trust Services)

All input that comes from a user may be malicious. Do not rely on your users to be nice to your system. Use sanity checks to make sure that the data you get from your users does not contain anything malicious. For example use prepared statements or model bindings when performing database operations. The most framework will support you with these programming paradigms and prevent things like SQL-injections.

The same is valid for input you get from third party services such as your payment provider. If they have a problem with their security, this should not affect you. For example check if their payment confirmation matches the data you have sent before allowing customers to use your service.


Separation of Duties

Users or services should only be able to do the tasks which are needed in their role. For example a normal user should not be able to log into an administrator interface. An administrator should not be able to log in as a user and use the software on their behalf. Similarly, a service should have its own database where he can log in to. Ho should not have access to databases from other services. This goes hand in hand with the Principle of Least Privileges.


Avoid Security by Obscurity

Most things get better if people have a look at it. The security of your system should not be dependant that some important information are not known. For example an administrator interface which is available via a secret URL but has no further security checks is a bad idea. If somebody by accident accesses the site, he can really screw your system. Still, you can keep the URL secret, but this should only be some add-on and not the security measure for the system.


Use standard algorithms

Do not create your own encryption algorithms. Good encryption algorithms have been undergone thorough reviews. Competitions chose encryption standards based on the research of mathematicians and cryptographers. Even though you may have pretty smart people in your company, it is very likely that they do mistakes when implementing their own encryption. The same goes for hash functions, (pseudo) random number generators, and so on.


Keep Security Simple

The more code you have, the more possibilities for attack surfaces. Even if it may be hip to use a bunch of different services and a complicated design, this comes with the drawback of complexity. Just keep it simple for security's sake.


Fix Security Issues Correctly

Always appreciate it when somebody tells you about a security problem in your software. Do not think about pressing legal charges or prohibiting to talk about the issue. Just fix it correctly! Most people who will tell you about a vulnerability do want to help you. Just ask them how they found the vulnerability and let them support you in finding the cause of the problem. Make sure that you implement the fix in all affected parts of your software. For example a problem with the login mechanism may not only affect the user software but also an administrator interface if the login code is a shared codebase. Test the fix thoroughly and at best: Automate the test, so that you will know if the problem arises again.


Free Security Check

We at Crashtest Security provide a security scanner for companies developing web applications. A free security scan on our website can already give insight in the security and show security issues. Check out the free security scan at

Topics: DevSecOps

Janosch Maier

Written by Janosch Maier

Co-Founder @ Crashtest Security. I write and give workshops regarding Web Security

For more information on all topics around continuous security, visit our continuous security page:

Continuous Security Topics