Prohibiting the use of banned APIs is a good way to remove a
significant number of code vulnerabilities — this practice is reflected
in Stage 6 of The Microsoft Security Development Lifecycle: “Establish
and Follow Best Practices for Development.” It can also be referenced
in Chapter 11 of the Microsoft Press Book The Security Development Lifecycle.
the C runtime library (CRT) was first created about 25 years ago, the
threats to computers were different; machines were not as
interconnected as they are today, and attacks were not as prevalent.
With this in mind, a subset of the C runtime library must be deprecated
for new code and, over time, removed from earlier code. It's just too
easy to get code wrong that uses these outdated functions. Even some of
the classic replacement functions are prone to error, too.
list is the SDL view of what comprises banned APIs; it is derived from
experience with real-world security bugs and focuses almost exclusively
on functions that can lead to buffer overruns (Howard, LeBlanc, and
Viega 2005). Any function in this section's tables must be replaced
with a more secure version. Obviously, you cannot replace a banned API
with another banned API. For example, replacing strcpy with strncpy is
not valid because strncpy is banned, too.
Also note that some of
the function names might be a little different, depending on whether
the function takes ASCII, Unicode, _T (ASCII or Unicode), or multibyte
chars. Some function names might include A or W at the
end of the name. For example, the StrSafe StringCbCatEx function is
also available as StringCbCatExW (Unicode) and StringCbCatExA (ASCII).
I'm not a developer, but I play one on TV. If you, however, are writing any code, you should read this article by Microsoft.