Buffer overflow attack, to gain injection and execution of code, usually leading to compromise of the machine. Also heap overflow.
SQL Query Injection attack, causing database engine to execute unauthorized database statements. This threat also covers similar attacks on other databases or downstream services like shell scripts (command injection).
Access control, signature verification, or other security feature not implemented. Testing only positive cases can easily ignore this type of threat. It is imperative that the test suites also include negative testing.
Input MUST at all times be validated to conform to the expected syntax, and input in general should never be trusted unless there is a cryptographical or structural guarantee of trustworthiness. Some particular perils
Explicit inputs
Environment variables
URL and query string
CGI form fields
Cookies
HTTP headers
SOAP headers
Processing contexts of all sorts passed between software modules
Fields of certificates (from untrusted source, but you would not know until you manipulated the certificate to find out if it is trusted).
Metadata
Messages from event bus
Data coming from database (even if database is supposed to be trusted, it may have been compromised, thus checking for proper format will help to detect the breach and contain it).
Deserialization of any data. This is particularly acute whan using eval to deserialize JSON data.
Perl(1) tainted feature provides a way to track untrusted user input. All untrusted input MUST be scrutinized for attack vectors, such as directory climbing (".." or "~" = home directory) as a path component. Where relative path is expected, an absolute path - one starting by "/" - MUST NOT be allowed. All shell(1) or SQL escape characters (see also T152-Inject) are of highest suspicion until proven to be secure.
When validating input, preferred strategy is to test if input is good and anything that does not pass is bad. The alternative strategy of looking for known bad things (like ".." in path) is much weaker and prone to errors.
Code MUST NOT
Dereference a Null Pointer
Use Freed Memory
Doubly Free Memory
Format string mismatch. In printf(3) format string it is easy to get the format specifiers and actual arguments mixed, resulting inappropriate format specifier being used for a given piece of data.
Truncation of value. Sometimes truncated value can have different meaning.
Signed conversion of a value that may not have been identified.
Reliance on client side validation is no good for server as an alternate client will not perform the validation. Server MUST at all times perform all security critical validations. Client side validation has value in (i) improving user experience and feedback, (ii) reducing network traffic by not submitting obviously invalid inputs, (iii) protecting client side processing like AJAX applications. Such applications MUST be suspicious of what is sent to them by server, in particular if they use JSON and plan to use eval() for processing it.
Cross Site Scripting.
Stack overflow. Similar to T151-Overflow, but specifically applied to the argument and call stack of most compiled programs.
Using non-validated input in the HTML output stream. This could lead into insertion of JavaScript on the generated page.
Improper Pointer Subtraction
Assignment (=) instead of comparison (==).