62 pages. For comparison, let's look at the simple rule you need to follow to avoid buffer overflows:

Count.

Buffer overflow cost so far to the industry? In the billions, at least: companies buy hundreds of millions of dollars of products every year as countermeasures against them. And that's for a bug whose fix can be described in one word.

The article is about sql injection not buffer overflows.

But the advice is also simple: 99% of the problems are solved by using parameterized queries ( pretty much every language/db library has them )

You missed his point.

Preventing buffer overflows is simple and well understood, yet it's still a problem. Preventing SQL injection is not as simple.* He's pointing out that if we have big problems even in the presence of simple solutions, we'll have even worse problems with not as simple solutions.

*Your solution might be "simple," but it's still more complicated that making sure you don't overrun your buffer.

ah yes, good catch

I misread that

Yeah... Param Queries also have a lot of other advantages in their usage too... As do the other techniques of using Stored Procs and Views.

I've always wondered why this isn't just a no-brainer.

To cut a long story short: ignorance.

Most people just don't have a security mindset. They are happy when it works the way it is supposed to.

The paper is largely about situations where parameterized queries aren't practical. See the section "Definition of dynamic SQL syntax template".

Correct title is "How to Write Injection-Proof PL/SQL"

Another instance of xkcd seen in a "serious" context: page 14.