|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #65257 new function for preventing XSS attack
Submitted: 2013-07-13 14:31 UTC Modified: 2018-07-07 22:59 UTC
Avg. Score:4.3 ± 1.1
Reproduced:3 of 3 (100.0%)
Same Version:2 (66.7%)
Same OS:0 (0.0%)
From: masakielastic at gmail dot com Assigned:
Status: Suspended Package: JSON related
PHP Version: 5.5.0 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:
From: masakielastic at gmail dot com
New email:
PHP Version: OS:


 [2013-07-13 14:31 UTC] masakielastic at gmail dot com
were added in PHP 5.3 for preventing XSS attack, 
a lot of people don't specify these options.

The one of PHP's goal is to provide a secure way for creating 
web application without CMSes and frameworks. 

The one of mesures for the problem is providing new function 
with make these options default.
Adding recommend opitons as a default also make sense.

function json_secure_encode($value, $options = 0, $depth = 512)
    // an option replacing ill-formd byte sequences with substitute characters

    $options |= JSON_HEX_TAG 

    return json_secure_encode($value, $options, $depth);

A shortcut for these options may be helpful a bit.

if (!defined('JSON_QUOTES')) {

The following RFC shows various functions for less options.

Escaping RFC for PHP Core

Ruby on Rails provide json_escape via ERB::Util.

OWAPS shows the guidelines for XSS attack.

RULE #3.1 - HTML escape JSON values in an HTML context and read the data with 

As a sidenote, the default HTTP headers of Rails 
include "X-Content-Type-Options: nosniff" for IE.

The following articles describe JSON-based XSS exploitation.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2013-07-26 21:23 UTC]
Sounds good to me. Anyone else have comments?
 [2013-07-26 22:31 UTC]
Alternatively, we may introduce JSON_UNICODE and make it default. Unicode escape 
is defined in FRC4627. e.g. \uD834\uDD1E

This would be most secure way of escaping unicode. The disadvantage is increased 
data size.
 [2013-07-27 11:13 UTC]
I don't really understand this issue (and also why the JSON_HEX_* flags were necessary in the first place). If you are going to embed JSON into HTML, why not use the usual htmlspecialchars function? Why do we have to implement HTML escaping functionality inside json_encode? Both things seem very distinct to me.
 [2013-07-30 02:13 UTC]
JSON is plain javascript code and pasting it to javascript code part in HTML is 

Therefore, ",',<,>,\ and others may allow injections.

PHP would better support all RFC4627 escape and set the most secure method as the 
default, IMHO.
 [2013-08-04 12:14 UTC] j dot tvr at centrum dot cz
Could you provide an example of XSS injection caused by json_encode which could not be resolved by proper usage of htmlspecialchars?

Side note: JSON is not subset of JavaScript due to U+2028 and U+2029 ( Although json_encode without JSON_UNESCAPED_UNICODE flag does generate a JS subset.
 [2013-10-03 00:02 UTC] phpmpan at mpan dot pl
When I see this proposal, voices in my head start singing "welcome back, magic_quotes" ;).

I would consider putting a proper warning in the documentation to be a much more appropiate solution. Now this issue may be simply overlooked, because such parameters like $options are often considered "optional things I'll probably not need now". However, if the issue is described and someone still doesn't see the risk or can't deal with it properly, then the author will create many security holes in the application anyway.

Also, if a new function is added, please don't use word "secure" in its name. Such names make more harm that good, when inexperienced coders come across them. Name it, for example, "json_js_encode" and describe it as one that emits a valid ECMAScript code that limits (not stops!) XSS attacks.
 [2018-07-07 22:59 UTC]
-Status: Open +Status: Suspended
 [2018-07-07 22:59 UTC]
> JSON is plain javascript code and pasting it to javascript code
> part in HTML is valid.

Wouldn't that imply, that pasting plain “javascript code” into an
“javascript code part in HTML” would be valid? …

Anyhow, this feature request is obviously controversial, and as
such clearly demands discussion on internale@, and perhaps a
follow-up RFC.  For the time being, I'm suspending this ticket.
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Wed Jan 26 18:03:34 2022 UTC