It’s 2016 – and yet, somehow, ‘easy-to-avoid’ vulnerabilities like SQL injection and XSS can be found on websites of government agencies, Global 500 companies, as well as in highly sensitive medical and financial applications developed and deployed around the world. Two decades of the same kinds of attacks and we still haven’t gotten secure application development figured out.
Why isn’t secure application development a standard in all organizations? How could VTech have been hit so hard by an SQL injection, when childrens information was at stake? How have major e-commerce sites like eBay or Magento or tech companies like Yahoo continued to be dogged by XSS flaws – all incidents in January of this year? The attacks may be more sophisticated, but the methods are the exact same – how can these mistakes keep popping up?
The main reason? Because we’re human – and humans make mistakes. Developers, testers, security experts alike – we can all stand to do more towards helping improve security in our respective organizations. One of the best ways to improve is to learn from our mistakes. Here are five of the most common secure application development mistakes we see, and how to do better:
The Most Common Secure Application Development Mistakes – And How You Can Avoid Them:
Forgetting to consider security during the design and requirements stages
One of the biggest mistakes made during development is before development even begins – in the planning and design stages. Not designing with security in mind opens the application up to more scrutiny later in the SDLC – something a secure SDLC is designed to help avoid.
When planning out an application, it’s crucial to consider which security mechanisms need to be implemented where, how the attack surface can be minimized, and identify sensitive areas where secure development can be helped by providing a secure infrastructure to developers to work with.
Instead of waiting until the testing phase to find security issues, a more proactive approach would be to build secure frameworks to work with, such as input validation and encoding libraries so that SQL and XSS issues are nearly impossible. Avoiding cases where developers code-on-the-go, we can dramatically cut down on the number of vulnerabilities introduced in the application. In addition, by designing with security in mind, the development process can go quicker when it comes to security checkpoints, while still producing a secure end product.
Not educating developers in secure coding practices
Developers are a lot of things – but they’re not wizards (at least, not in their day jobs). They won’t magically come into work one day knowing how to code securely. Not without your help, at least. Another common mistake in secure application development (or lack thereof) is neglecting to pave the way for developers in learning more about application security.
By keeping all security testing until the end of the SDLC, you’re increasing the risk of having to break the build at a late stage or allowing flaws to leak into the app – and without teaching developers to code securely, you’re never going to be able to get ahead of security issues, especially as development cycles continue to shorten.
With agile environments paving the way for how all organizations will run in the near future, secure coding is essential for the longevity of any organization to be viable. Security cannot be bolted on – it needs to be built in, and can only be achieved with the help of your development team.
There are plenty of ways to go about fixing this, but the key is to keep security awareness and education programs engaging and directly relate it to what developers are working on. Educate them in secure coding techniques, using the languages they’re coding in and relatable examples that could easily be applied to their work.
Neglecting to check for OWASP Top 10 vulnerabilities
There’s a reason these security vulnerabilities are on an industry-standard Top Ten list – they’re abundant and they have the potential to be lethal to businesses and individuals alike. If you’re not adamant about developing with the Top Ten vulnerabilities in mind and testing for the flaws before release, you’re headed straight for the next breach checking apps for the OWASP Top Ten vulnerabilities, you’re making a big mistake.
Obviously, the vulnerabilities included in the Top 10 list aren’t the only issues you need to be looking for, but they can act as a good starting point, especially for organizations just starting to implement security testing. With an OWASP Top Ten cheat sheet geared towards developers in mitigating the Top Ten flaws, there’s no reason any organization developing applications shouldn’t be watching out for at least those issues.
Treating functionality and performance bugs with a higher regard than security bugs
This is something common in every organization in any industry, around the world – functionality trumps security when it comes to the “bottom line.” But we’ve seen enough organizations fooled by that myth to know it’s a big mistake to think that way. Yes – performance and functionality are important aspects of any application and your users deserve high-quality products.
Yet security needs to be considered equally – and we can no longer afford to compromise security for some sparkly feature. Don’t let neglecting security in favor of speed or number of features be your applications’ Achilles heel!
Not testing the app before each new release
Each new release offers new code to attackers to find flaws to exploit. One mistake we’ve seen is organizations deploying small updates in their applications without scanning the code changes. Don’t skimp on security testing future releases, no matter how small the added changes. Ensuring that libraries are called correctly, added components secure, and new code free of vulnerabilities needs to be done each time you update an application.
With incremental scanning available in the newer SAST tools, testing for security flaws with each new update doesn’t need to cause delays. Testing only the newly implemented code and their dependencies, incremental scanning can save lots of headaches and resources caused when security testing slows down the SDLC.