base64_decode: reject inputs with non-base64 characters (fail safely)

[touchweb-vincent]

Description

Hello,

I’m fully aware that I’m raising an issue that isn’t directly caused by PHP itself. However, since we haven’t been able to find any viable technical solution that doesn’t either introduce or worsen a chain of erratic side effects - some minor, some not - I would truly appreciate it if you could give this matter some attention.

base64_decode currently accepts inputs containing characters outside the Base64 alphabet, which can trigger erratic behavior in downstream systems.

<?php echo base64_decode('P~.F$.~N~~Dc~.mlwd~Ao.+~IG~$FsZ.XJ0.K.D$c5Nik8L1$N$~D$cmlwdD.4~7$$');

It would be highly appreciated if this could fail loudly - ideally with a fatal error or exception - when the input is not strictly valid.

This behavior causes issues for security infrastructures and DevSecOps teams, as many systems downstream of PHP (WAFs, proxies, forensic tools) rely on strict decoding logic - unexpected input can cause failures, inconsistent behavior, or even crashes.

owasp-modsecurity/ModSecurity#3327

Thanks you

Vincent

[TimWolla]

Related: https://externals.io/message/127716#127716

[jack-worman]

It would be highly appreciated if this could fail loudly - ideally with a fatal error or exception - when the input is not strictly valid.

You can use the strict parameter to have it at least return false:

$result = base64_decode(
    string: 'P~.F$.~N~~Dc~.mlwd~Ao.+~IG~$FsZ.XJ0.K.D$c5Nik8L1$N$~D$cmlwdD.4~7$$',
    strict: true,
);
var_export($result); // false

[touchweb-vincent]

From a hosting provider's point of view, it's not possible for us to intervene in our clients' source code.

We would therefore prefer that this not be configurable, and that the strict mode be the only available mode.