Pushing Left, Like a Boss, Part 5.14 Secure Coding Summary

This article will summarize the previous articles in Part 5 of this series, and is hopefully something that you can use for your organization as a start for a secure coding guideline for your developers.

Secure Coding Guideline

• 1. Input validation should be used in every possible scenario. This includes Redirects and Forwards.
• 2. Output Encoding is required for all output.
• 3. Parameterized Queries are mandatory.
• 4. All 3rd party code must be verified not to contain known vulnerabilities.
• 5. Every applicable security header should be used.
• 6. All client-side and browser hardening strategies available to you are required, as outlined here.
• 7. Use the identity and session management features available to you in your framework or from your cloud provider and follow this guidance.
• 8. Take every possible precaution when performing file uploads, including scanning it for vulnerabilities such as AssemblyLine.
• 9. Nothing of any consequence should ever be stored in URL parameters.
• 10. Sensitive data should be stored in secure cookies, and all available security features for cookies should be used.
• 11.All errors should be caught, handled and logged, as per this article. Never log sensitive information.
• 12.Do not trust data, always verify.
• 13.Use the Authorization features in your framework, do not write your own.
• 14.Use the Authentication features in your framework, do not write your own.
• 15. HTTPS only. Use only unbroken and industry standard protocols (currents standard is 1.2 TLS).
• 16. Always use the security features in your framework and never write your own. Always keep your framework up to date.

In order to ensure that your developers are following these 
guidelines, code review is recommended.

I’d like to thank all of my professional mentors and the OWASP volunteers that have taught me about Application Security, that is where and how I have learned the majority of what I know on this topic. Without the OWASP community, and it’s free and vendor-neutral teachings, many of us would not be where we are today. The OWASP community has my unwavering and unending gratitude and support. Thank you.

Special thanks to the following people who have helped me directly in learning these concepts, and so much more: Dominique Righetto, Jim Manico, Sherif Koussa, Adrien de Beaupre, Sonny Wear, Nicole Becher, Chenxi Wang, Zane Lackey and Kim Tremblay. I’d never have gotten this far without them.

If you like this blog series, you will love the OWASP Cheat Sheet project! My favorite OWASP project of all time. Check it out!

Up next in part 6 we will discuss the testing phase of the SDLC, what types of security testing we can do, the approaches we can take, as well as other strategies and phases within the SDLC that we can test our apps.

Do you have any more secure coding principles that you would like to add? Guidance you’d like to share? Please add it to the comments below!