The Open Web Application Security Project’s (OWASP) Secure Coding Practices Quick Reference Guide is comprehensive but anything but quick, with 218 recommendations grouped into the following 14 categories:
- Input validation
- Output encoding
- Authentication and password management
- Session management
- Access controls
- Cryptographic practices
- Error handling and logging
- Data protection
- Communication security
- System configuration
- Database security
- File management
- Memory management
- General coding practices
But there is also less daunting training to get coders started. Secure Code Warrior, which notes on its website that “the same 10 software vulnerabilities have caused more security breaches in the last 20-plus years than any others,” offers guidance on how to recognize and avoid them. They include file upload, server-side request forgery, cross-site scripting, SQL injection, password storage vulnerabilities, and the use of components with known vulnerabilities.
Finally, there are more general principles and techniques that can help coders develop a security mindset.
Verify, then trust. One of the first things to understand is that coding includes using more than what a single developer has written.
Vineeta Sangaraju, senior research engineer with the Synopsys Software Integrity Group, said that “no one typically writes every single piece from scratch. You depend on the programming language’s libraries.”
And those libraries don’t always come from the creators of the programming language. “As the world of coding progressed, some libraries were not the official parts of that programming language or framework,” Sangaraju said. “They were being created by third parties.”
There are benefits to that. “Coders have even more options when choosing the libraries,” she said. “Instead of writing a method from scratch, they will just import the third-party library and use its methods instead.”
But that also leads to an important rule of offensive security. To trust any library, coders need to check both what they’ve written and what somebody else wrote. “They need to scrutinize the third-party library and only trust verified publishers,” Sangaraju said. “In the current world, sometimes these libraries have unsecure code so if a coder uses them, they’re inadvertently introducing security weaknesses into their code.”
That principle also applies to any external data. “When you’re coding functionalities that deal with external input, it is important to understand the risks involved and to mitigate them with controls,” Sangaraju said. “For example, are you requesting profile details from the user? Then sanitize user input before it is saved in the database.”