go to bug id or search bugs for
When any object is passed through filter_var() with the FILTER_VALIDATE_INT filter and a default option the result is always boolean false instead of the default value.
Second, the FILTER_NULL_ON_FAILURE flag also shows no effect on passed objects.
$id = filter_var(new stdClass, FILTER_VALIDATE_INT, [
'options' => ['default' => 2],
Add a Patch
Add a Pull Request
I can confirm both issues: <https://3v4l.org/mAtsv> and
The first issue has been introduced with the fix for bug #49274,
where the function bails out too early thereby ignoring any
The second issue is actually a duplicate of bug #67167, which has
been fixed (in this regard) only as of PHP 7. The fix should be
backported to PHP 5.6.
Automatic comment on behalf of firstname.lastname@example.org
Log: Fix #73054: default option ignored when object passed to int filter
I came across this bug fix bug.
Currently, VALIDATE filter returns default values for _invalid_ parameter value/type.
Sanitizing filter may ignore _invalid_ parameter value/type.
However, validation filter must not ignore _invalid_ parameter and must not use default value. It should treat invalid parameters as error.
BTW, ignoring invalid values is now considered as security vulnerability.
See OWASP TOP 10 2017 edition RC. (A7 Insufficient Attack Protection)
> Currently, VALIDATE filter returns default values for _invalid_
> parameter value/type.
Indeed, and this behavior is documented:
| When default is set to option, default's value is used if value
| is not validated.
This part of the documentation has been committed by you, by the
way, see <http://svn.php.net/viewvc?view=revision&revision=331940>.
Anyhow, this bug fix only changes the behavior with regard to
objects to be consistent with the behavior of otherwise invalid
values, see <https://3v4l.org/IVO7g>, so please open a new ticket
if you think the behavior is erroneous.
Thanks, I'm responsible for this then.
New OWASP TOP 10 considers current behavior as vulnerability.
I'll submit change proposal.
I've proposed fix already.
The patch behaves as it should. This RFC is declined, though.
I shall propose the RFC again, since current filter module lacks the most important filter/validation. i.e. String filter/validation.
We may be better to have distinguished API for validation and sanitizing. i.e. New module and new API for these.