|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #69908 Accept array for htmlspecialchars/htmlentities
Submitted: 2015-06-23 09:01 UTC Modified: 2020-10-27 10:35 UTC
Avg. Score:1.0 ± 0.0
Reproduced:0 of 2 (0.0%)
From: Assigned: yohgaki (profile)
Status: Suspended Package: Strings related
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
New email:
PHP Version: OS:


 [2015-06-23 09:01 UTC]
htmlspecialchars/htmlentities only accepts string to be escaped.
Accept array and escape all elements when array is passed to them.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2015-06-23 09:01 UTC]
-Assigned To: +Assigned To: yohgaki
 [2015-06-23 09:08 UTC]
What about all the other functions that take a string? add[c]slashes, bin2hex, md5, trim, [raw]urlencode... And what about html_entity_decode and htmlspecialchars_decode?
 [2015-06-23 09:39 UTC]
I can take care of them also.

I also notice that current  php_html_entities implementation is not optimal.
It can take 1st parameter as zval and convert int/float simply to string.
 [2015-06-23 15:27 UTC]
I think this is the exact wrong way to solve the problem. Very rarely do you want to actually just do a "blind escape" of a bunch of variables. Instead, you need to know the context they will be used in. By accepting strings only, these security sensitive functions encourage you to use them exactly at the point of output, and hence in a contextual manner.

Instead, if you allow escaping arbitrary elements (arrays, objects, etc) then the contextual guarantees disappear, as well as pushing the escaping further from the point of output. This makes it harder to actually verify and reduces the overall security.

Not to mention that it makes the API a lot harder to follow and a lot more "magic". Both of which are clear negatives on a security sensitive API.
 [2015-06-24 02:27 UTC]
I can understand your argument very well. Output security depends on "output context". 

This change is intended to escape relatively large number of variable at once. For example, HTML tables that have a lot of variables. The objective is not for improving security, but performance.

We should balance security and performance/usability. Since I'm going to add array parameter support for conversion functions, we need to consider consistency also.

I'll create RFC for this.
 [2015-06-24 13:58 UTC]
> Accept array and escape all elements when array is passed to them

Why not just:

array_map('htmlspecialchars', array ('&', '>', 'foo'));
 [2015-06-25 01:26 UTC]
It will make situation better, but not enough.

I'm looking for optimization on IoT devices that took more than 10 sec to generate log report page by PHP. More than half of time is took by htmlspecialchars() and do the best htmlspecialchars() can do.
 [2020-10-27 10:35 UTC]
-Status: Assigned +Status: Suspended
 [2020-10-27 10:35 UTC]
This feature request is obviously controversial, and as such needs
to be discussed on the internals mailing list[1].  If you're still
interested in having this, please forward your request to the
list.  For the time being, I'm suspending this ticket.

[1] <>
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Sun Nov 28 19:03:38 2021 UTC