El problema de los lenguajes no tipados es que te puedes encontrar con errores tan sutiles como este. Validando un precio (básicamente un número), el programa hacía lo siguiente:

“123″ => Correcto
“-123″ => ERROR!
“0″ => Correcto pero no se usa
“” => Correcto pero no se usa
“123asd” => ERROR!
“asd” => Correcto pero no se usa                 <<<<<<===== WTF!?!?!?!

Debería haberme escupido un error en el último caso!
Trazando el código me encuentro que se comprueba y pone a cero tal que así:

if (isset ($this->price) && $this->price == 0) $this->price = NULL;

Por qué entra en el if cuando “asd” es claramente diferente a 0?
Porque en PHP, al estar comparando una cadena con un entero, se intenta hacer una conversión emplícita a entero de la cadena y al no poder, queda el if tal que asina:

if (isset ($this->price) && NULL == 0) $this->price = NULL;

Y ese NULL==0 se evalúa a verdadero por las reglas de comparación de PHP.
Vamos que he estado dándole vueltas un rato a esto, para que ahora la solución se base en añadir un carácter convirtiendo la comparación de igualdad en una comparación de identidad:

-        if (isset ($this->price) && ($this->price == 0 || $this->type != ‘s’)) $this->price = NULL;
+        if (isset ($this->price) && ($this->price === 0 || $this->type != ‘s’)) $this->price = NULL;

Interacción insegura entre componentes:

• Validación de parámetros de entrada inapropiada
• Codificación o escapado de parámetros de salida inapropiados
• No preservar la estructura de las peticiones SQL (Inyección de SQL)
• No preservar la estructura de la web (Cross-Site Scripting)
• No preservar la estructura de los comandos del sistema operativo (Inyección de comandos del SO)
• Transmisión en claro de información sensible
• Suplantación de identidad al hacer peticiones de información (Cross-site request forgery)
• Condiciones de carrera
• Filtrado de mensajes de error

Gestión de recursos arriesgada:

• No limitar las operaciones que ocurren dentro de los límites de un buffer de memoria (Buffer Over/Underflow)
• Control externo sobre datos críticos de estado
• Control externo sobre nombre de archivo o ruta
• Ruta de búsqueda no confiable
• No controlar la generación de código (Inyección de código)
• Download de código sin chequeos de integridad
• Cierre o liberación de recursos de manera inapropiada
• Inicialización inapropiada
• Calculos incorrectos

Malas defensas:

• Control de acceso inapropiado (autentificación)
• Uso de un algoritmo de criptografía roto o arriesgado
• Passwords imbuídos en el código (Hard-coded passwords)
• Asignación de permisos insegura a un recurso crítico
• Uso de valores aleatorios predecibles
• Ejecución de código con privilegios innecesarios
• Forzar contoles de seguridad del servidor en el lado del cliente

Personalmente, me he encontrado con casi todos ellos en algún momento y aunque algunos pueden resultar sencillos de identificar y resolver, otros pueden llegar a dar verdaderos dolores de cabeza.

El de los valores aleatorios me ha recordado uno de los comics de xkcd: