Developers should take in consideration some security best practices while coding, even when you have digital security teams. It doesn’t mean Software Engineers should be expert on this matter, but there are so many resources we can use to avoid common security breaches! That will make your digital security personnel happy and thankful for having time to dedicated to more complex and specific validations. I would like to show five tips on how to increase security standards on you web applications, accessible to developers. This means all of these checks/best practices are totally feasible for coders and general Software Engineers, and can be easily incorporated on you workflow, some even on automated pipelines.
Why should I care?
Most of the security breaches are caused by software defects. The incredible thing is that almost all of them are very clear on OSWAP top #10 vulnerabilities. So, the bad practices are very clear, why the same breaches keep occurring? Sloppiness is a thing to blame, but not the only one. Sometimes misinformation takes a huge portion of it. The following tips help you to avoid both cases and even automate some of the common validations.
1. Be aware of most common security mistakes
The first thing about security is to know the most common breaches. It seems obvious, but things like SQLInjections and Broken Authentication are almost as old as the Web, but still present in many systems. A quick read through OSWAP top #10 vulnerabilities can give you a glance of the first things attackers try to exploit in a web service.
As long as security is your (and your team) concern, it will turn out a natural, organic check on your development list. Don’t you think automatically about test coverage? code duplication? Avoiding security leaks will also be in your mind after some time of practice.
2. Talk about security on your code review
Code review is one of the best opportunities to look out for security breaches. Sometimes your eyes will get used to an suspicious structure, and a colleague will spot the problem in a minute. In other cases, a more experienced team member can catch unsafe code that you missed. That’s why it is important to have good checklists on this step and be sure critical pull requests get more attention the security matter.
3. Follow up your dependencies
Third part components are present on almost every software today. As you can let pass some unsafe code, external maintainers can too. For example Django, the most famous Python framework, just had a SQLInjection breach exposed. How many days you would need to update this dependency if you didn’t now about it?
Is it important to keep track of (at least core) dependencies. Not just to be part of the community, take a peak on new versions and improvements, or even finding good learning material. Projects use twitter, official blog and even newsletters to tell the community what is happening, specially about security.
I personally follow Python, Django, Flask, PostgreSQL and Vue.js in different medias, aware of any kind of news. There are other projects I keep close on twitter. It is a good practice not only for security standards, but also on general Software Engineering.
4. Keep it up to date
Better put: keep you dependencies able to update. Some projects have a hard time keeping up with the most updated version of some components. Ideally, third part dependencies should be easy to detect and to replace. Decoupled components are easier to update because you can track API changes that will impact on your code. And if they are not doing a good work, you can seek alternatives without too much trouble. In addition to receive community performance improvement and new features, you will have the “top of the line” upgrades on security.
On critical scenarios, code bases are so messy that dependencies are kept outdated for years. This means even security updates are no longer supported by the community, letting the software exposed to well known vulnerabilities. The older and broader is the breach, more open it is to be exploited.
5. Put verification tools to work
You are not alone on this endeavour! There are plenty of tools you can use to help you test (and keep testing) you web service’s security, and many of them are online. For instance, SecurityHeaders help you to check whether you have the appropriate headers being sent on HTTP responses. Those help you avoid phishing, XSS and other common attacks. There are other, broader tests you can use to have a idea about security issues a web service is exposing.
We can’t forget about code verification tools. CodeClimate and SonarCube have a whole category dedicated to security issues, very useful. Snyk can also evaluate your dependencies, working both online and offline. You have even simple CLI tools like Bandit and Vulture for Python that can be easily integrated on your workflow and CI/CD pipelines, just like a linter or formatter would. A personal favourite is to use nmap to scan for vulnerabilities. There are lots of scripts, specially for the most common and widespread breaches.
*Bonus Tip*: SSL certificates
The days of not certified sites are over. Google Chrome and other browsers already call your site unsafe, plain and simple, if they’re not under a valid issued SSL certificate. However, it is hard to find a excuse for not having one when Let’s Encrypt is out there, bigger everyday. You can get a trustworthy, auto renewable SSL certificate for free! You can easily use it with Nginx, Apache or even with Docker. You can use it as a proxy, if your legacy app is giving you trouble on this matter.
Conclusion
Those tools are better when used together, alongside of thoroughly Code Reviews and software engineer best practices. But they let the humans focus on important discussions, not on easy to miss little flaws. This makes the workflow more easy and secure, letting your applications ready to the wild web out there. Do you have more tips on web security for developers? Want to share a tool that I missed? Speak up! :)