Fostering Secure Coding Practices for Web Applications

The Pros and Cons of Security Checklists

It’s tempting to define secure coding requirements simply as a list of do’s and dont’s for developers. In fact, you can go straight to the Open Web Application Security Project for the OWASP Secure Coding Practices Quick Reference Guide – a detailed checklist of well over a hundred great points related to security. It’s the perfect place to start when learning about application security and a great reference designing and testing applications.

The problem is that you can’t simply give developers a checklist and say: “Follow this list to be secure”. Or rather you can – but it won’t work. Application development is about creating something from nothing while meeting business requirements and deadlines. It’s about making new things and finding ways to make them work. It’s not about ticking off security checklists.

Good coding practices are like scales when learning a musical instrument or technique exercises in sports training: you should know them so well that you don’t have to think about it. The only way to get good at secure coding is through education, training, and lots of practical experience. Unless you’re selecting topics for developer training, a secure coding checklist is not a tool for directly improving your application security.

Using Secure Components and Technologies

When it comes to security, even the smallest mistake or incorrect assumption can open up a vulnerability downstream. That’s why a fundamental part of secure coding is knowing when to bring in external code and when to write your own. Every development environment should include a curated set of trusted, secure, and up-to-date components for common tasks so developers don’t need to reinvent the wheel (and risk introducing vulnerabilities in the process). After all, application developers are supposed to focus on writing good applications, not researching cryptographic practices or communication security. This is especially important for new and trending technologies, where tested and secure implementations might not yet exist or be widely known.

Your approach to secure coding will also differ depending on your choice of frameworks and programming languages. On the server side, modern web applications are written almost exclusively in high-level interpreted languages, such as Java, Python, PHP, or C#, so at least buffer overflows and similar low-level vulnerabilities are not an issue. Importantly, all these languages have extensive and mature standard libraries that developers should know and constantly use. A good rule of thumb (not just for reasons of security) is that you should only write custom code for business logic. For everything else, from error handling to string concatenation, you should use built-in functions wherever possible because that saves you time and money – and because they are more secure and better tested than hand-rolled code.

The same goes for front-end development where JavaScript frameworks are the order of the day. When choosing frameworks, you need to include security among your criteria – and a little extra time spent at this stage can save a lot of pain later. With the right framework and the right training, your developers can use built-in mechanisms such as input validation and output encoding to avoid many common security vulnerabilities, from cross-site scripting and SQL injection to authentication and authorization issues.

Incorporating Security Testing into Development

There is no question that secure software starts with secure code. Security testing tools and workflows need to be an integral part of the development process to ensure that developers get security feedback quickly and incorporate it into their work. Static analysis tools are the obvious choice for integration into the development toolchain, from simple IDE-based code-checkers to more advanced tools and plugins. While easy to introduce, static application security testing (SAST) tools tend to generate a lot of false positives and need to be fine-tuned to be effective. Because they work on the source code, you will also need a separate tool for each programming language you work with, which can get complicated (and costly).

To go beyond the source code and find runtime software vulnerabilities across the entire application as deployed, you also need dynamic application security testing (DAST). In agile application development environments, it is no longer practical to leave dynamic testing to the security professionals who then create tickets for the development teams. All security testing must be tightly integrated into the software development lifecycle (SDLC) so developers can get rapid feedback on security risks in their code and improve software security in the long run. 

A modern DAST solution such as Invicti can take the load off the security team by automatically confirming many vulnerabilities and creating actionable bug tickets directly in the developers’ issue tracker. It also helps to build secure coding practices by providing developers with information about the potential impact of vulnerabilities and detailed remediation guidance.

Security as a Mindset

Secure coding starts before the first line of code is even written. Of course, having the right tools and workflows is important, but the real challenge is building a security-first development culture. Secure coding principles need to go far deeper than just using parameterized queries and validating user inputs. Alongside functional and performance requirements, security must be a consideration from the very start of application design.

Putting security first is especially challenging for web application development, where the focus has traditionally been on quickly building new and exciting features in ways that simply weren’t possible just a few years earlier. When you add to this the challenges and complexity of cloud deployments, the only way to keep applications and sensitive data secure is to put security first in every decision, from design and implementation to deployment and operations.

This might seem paranoid at first, but when you look at cyberattack statistics and add up the potential cost of data breaches, outages, and all the other consequences of a successful attack, it starts to make good business sense. With so many companies dependent on web applications to do business, promoting a security-focused mindset all across the organization is the best way to make sure that secure coding practices are enforced and translate to long-term security improvements.