False positive on php.lang.security.injection.tainted-sql-string.tainted-sql-string

[LucianoHanna]

Describe the bug
The rule php.lang.security.injection.tainted-sql-string.tainted-sql-string produces a False Positive (FP) when user-controlled data is sanitized using numeric conversion functions or type casting. Specifically, when a variable is passed through intval(), it is no longer capable of carrying a SQL injection payload, but the rule still flags it as "tainted."

To Reproduce

<?php
$id = $_REQUEST['id'];

// Scenario 1: Function-based sanitization
$sanitized_id = intval($id);
$sql1 = "DELETE FROM categories WHERE id = " . $sanitized_id; // Flags FP

// Scenario 2: Type casting sanitization
$casted_id = (int) $_GET['id'];
$sql2 = "SELECT * FROM products WHERE id = " . $casted_id; // Flags FP

Expected behavior
The taint analysis should stop (be "sanitized") when the data flows through functions or language constructs that guarantee a safe numeric output. I expect the rule not to trigger when the variable reaching the SQL string has been processed by:

• intval()
• floatval()
• (int) / (integer) casting
• (float) / (double) / (real) casting

Priority

• P0: blocking me from making progress
• P1: this will block me in the near future
• P2: annoying but not blocking me

Additional Context
The current rule definition lacks common PHP numeric sanitizers in the pattern-sanitizers section. In PHP, forcing a value to an integer is a standard and safe practice for preventing SQL Injection when the expected input is a database ID or any numeric primary key.

To fix this, the following patterns should be added to pattern-sanitizers:

  pattern-sanitizers:
    - pattern: intval(...)
    - pattern: floatval(...)
    - pattern: (int) $VAR
    - pattern: (integer) $VAR
    - pattern: (float) $VAR