Mon, Aug 24, 2020
Disclaimer: I am not a security expert.
This post is a collection of quick tiny little things that could improve your security drastically. We would have a much safer web if more developers would know some of these resources and tips.
This might sound a bit weird, but checklists are a great and powerful tool.
Ever heard of the Surgical Safety Checklist from the WHO? In their study, this checklist reduced the morbidity rate of patients by almost 50% 1. This effectiveness will also apply to WebSecurity.
You will forget or don’t even know about some vulnerabilities. I recommend the OWASP Cheatsheet Project. The usefulness of this project is incredible. For one of my own Web-Apps, I forgot to install a CSRF Protection but saw them on the Cheatsheet.
I personally forgot to implement a CSRF protection for certain actions in my Web-App.
Or you should at least pretend so. Never trust any input that comes from your users. Imagine them as hackers.
This will put you in the right mindset.
Some of the most common vulnerabilities come from improper input handling.
Can you put restrictions on the input of your web app? Then do it. The stricter the better.
This also accounts for strange things like: Does your App accept a 1GB big JSON file?
Considering strange inputs, here is a list of strings which may break some applications. And you may test if that also breaks your app.
Additionally, ask yourself: “How would I hack my own app?”
This is also a great point from a non-security perspective. You should always know when something is wrong.
Only if you know something is wrong, you can fix it. I will again recommend a OWASP Cheatsheet about Logging.
If you noticed a security incident, be open to your users. Don’t try to hide something.
Being open about such incidents is important and builds trust. In most cases you are also legally required (GDPR Art. 34) to inform your users.
So, you tried your best to secure your app. Most likely there will be still vulnerabilities in there.
For this reason: Make it easy for security researchers to reach out to you.
Signal them you will not go after them if they didn’t break any laws. There is a high chance many security researchers will not search or report vulnerabilities because they are afraid of legal retaliation.
So, how do you do that?
Provide a Responsible Disclosure Policy.
In short, it states what security researchers are allowed to test and where to report them.
Bugcrowd (one of the biggest bug bounty platforms) provides a framework for creating such a policy and a more in-depth article about Responsible Disclosure Policies
Provide a security.txt file.
This is a standard proposed by a security researcher.
It’s basically a text file that states where you can disclose security vulnerabilities and how. You can create it easily via the official website.
Provide a security@example.com mail address.
Many researchers try this first.
If it fails, there is a lower chance a vulnerability will be reported to you.
If you don’t have any of these, it’s like a sign “No Good Hackers allowed here.”
If you want to read more about why we need more hackers, there is an excellent article here.
Security is hard. It takes time and work to do things more securely.
For the sake of a better web, try it.
We need more hackers that hack for good and more people that are aware of those pitfalls.
Further recommendation:
There are also techniques to write more secure code. I’ve heard good things about the book “Secure by Design” from Deogun, Johnsson, and Sawano.
Take a look at a good summary.
Got a website? I would be happy if you take a look at my new Project.
Haynes, A. B. et al. (2009) ‘A Surgical Safety Checklist to Reduce Morbidity and Mortality in a Global Population’, New England Journal of Medicine. Massachusetts Medical Society, 360(5), pp. 491–499. doi: 10.1056/NEJMsa0810119. ↩︎