CISSP 21.8 - Secure Coding Practices

This episode of the ISC2 Certified Information Systems Security Professional (CISSP) exam prep series closes the loop within Domain 8 with the secure coding habits that prevent the flaws studied throughout the chapter. It examines the same handful of mistakes that keep resurfacing across languages and frameworks: leaky comments, weak error handling, hard-coded credentials, AI-assisted coding risks, and poor memory management.

Frequently Asked Questions

Why can source code comments become a liability?

Comments are valuable for documenting design choices, but the problem is when they end up in the wrong hands. A comment can hand an attacker a road map of how the code works, and sometimes even contains secrets that should never be exposed. Compiled programs strip comments out automatically, but web applications can expose their source directly. The rule is simple: keep comments in your archived source for future developers, but remove them from anything published to the internet.

How does good error handling protect an application?

Attackers deliberately push code into strange situations to see how it breaks, so your code must expect the unexpected. Many languages offer try and catch structures, where risky code sits in a try block and the catch block defines how to respond when it fails. Error handling is a second layer behind input validation, catching anything validation missed. Show users only the minimum they need, while logging the full details privately, because overly detailed messages can leak your code’s inner workings.

What is wrong with hard-coded credentials?

Baking usernames and passwords directly into source code is a persistent and dangerous mistake in two flavors. The first is a hidden maintenance account, a backdoor whose leaked password compromises every deployed copy at once. The second is embedding credentials for other services, so if the code is disclosed, those secrets go with it, which happens all too often when developers push code into a public repository. The fix is to keep secrets out of source entirely, using secure configuration and secret management.

What risks come with AI-assisted coding?

As developers lean on artificial intelligence to write code faster, new hazards appear. These tools can hallucinate, confidently suggesting libraries or functions that do not exist or behave nothing like expected. Because they learn from vast amounts of public code, they can also quietly recommend insecure snippets carrying known vulnerabilities or subtle logic errors. The discipline is unchanged from any borrowed code: critically review, independently verify, and thoroughly test everything the AI produces before it ships.

How does poor memory management undermine security?

When applications manage their own memory, two problems stand out. The first is resource exhaustion, where a system consumes all its memory, storage, or processing until it halts, often caused by a memory leak that keeps requesting memory and forgets to return it. The second is pointer dereferencing gone wrong: following an empty, null pointer triggers a null pointer exception that at best crashes the program and hands an attacker debugging clues, and at worst lets them bypass security controls.

Reference: This article is based on concepts discussed in CISSP 21.8 - Secure Coding Practices.