Good hygiene and Banned APIs updated

Jeremy Dallman here with a quick note about an update to banned.h. Two years ago, we released banned.h, a code sanitization tool in the form of a header file designed to locate potentially insecure APIs (also known as “banned APIs”). In June, Tim Burrell guest blogged about the banned APIs extension to the Visual Studio 2010 IDE his team created to improve developer awareness of the banned APIs by providing a “red squiggly” line in their code to flag a banned API. Microsoft has been persistent about stating the risk and impact of using these banned APIs. We are always looking for tools that improve the ability for developers to discover and address them while coding.

In keeping with our goal to improve awareness of banned APIs, I would like to announce an update to the banned.h header. This update includes some new APIs that have been deemed potentially insecure.

You can download the updated banned.h header here.

What changed:

1. We broke the banned APIs into Required and Recommended categories:

· Required is a list of APIs with a history of vulnerabilities.

· Recommended is a list of functions you should consider removing from code over time. In general, these functions have less of a checkered history, but are potentially dangerous.

Required is enabled by default and you can opt-into Recommended by adding this line to your code before you #include banned.h:


2. Made banned.h work well with StrSafe

3. Banned.h is now a superset of the /W4 C4996 compiler warnings.

4. Although C4996 is a good basic security step, banned.h is a more complete solution.

An overview of banned.h

By including this header file, then using #include “banned.h”; you will be able to locate any banned functions in your code. The full list of banned APIs is also included in the header file. To reiterate what I said in 2008, if you are using the compiler in Visual Studio 2005 or later, you have a built-in way to check for these banned functions. To catch banned C runtime functions, you can compile with /W4 and then triage all C4996 warnings. In code reviews, you should always remove any code that disables the C4996 warnings – e.g.: #pragma warning(disable:4996). This is one simple way to release your code with confidence that it will not include banned functions, but as mentioned in the changes above, banned.h is how a superset of C4996 and should be prioritized.

Sanitizing your code to remove potentially insecure APIs is a vital protection practice. Whether you include the banned.h header file, utilize the banned API Extension in the Visual Studio 2010 IDE, or leverage the /W4-C4996 warnings in the Visual Studio 2005 compiler, you now have three seamless ways to check your code and meet another SDL requirement during development.

Join the conversation

  1. Anonymous

    The download link above points to the old version of banned.h as of 2008.

  2. Anonymous

    Will there be a new version of the SDL-BannedAPIExtension for Visual Studio 2010 to reflect the changes in the latest version of banned.h?

Comments are closed.