Nuking misleading properties in `Object.getOwnPropertyDescriptor`

David Bruant bruant.d at
Wed Mar 13 09:08:36 PDT 2013

Le 13/03/2013 16:49, Mark S. Miller a écrit :
> On Wed, Mar 13, 2013 at 8:26 AM, Nathan Wall <nathan.wall at 
> <mailto:nathan.wall at>> wrote:
>     David Bruant wrote:
>     > Tom Van Cutsem wrote:
>     > > To my mind, the blame for the breakage lies with
>     `Object.prototype`
>     > > being mutated by the third-party script, not with property
>     descriptors
>     > > inheriting from Object.prototype. Thus, a fix for the breakage
>     should
>     > > address that directly, rather than tweaking the design of
>     property
>     > > descriptors, IMHO.
>     > I agree.
>     >
>     > The first (security) decision any JavaScript application should
>     make
>     > would be to freeze all built-ins like SES [3][4] does. (In the
>     future,
>     > it could even make sense to add a CSP [5] directive for that)
>     > If necessary, the application can first enhance the environment by
>     > adding polyfills/libraries and such, but that's pretty much the
>     only
>     > thing that's acceptable to run before freezing everything.
>     Hey David and Tom.  This is good advice for application authors,
>     but I don't work at the application level; I write libraries.  I
>     don't want to freeze everything because I want to leave the
>     environment open to monkey-patching and shimming by other
>     libraries and the application authors. So this isn't an option for me.
>     > "what if an attacker switches Array.prototype.push and
>     Array.prototype.pop?"
>     These are issues that are easy to address by using stored
>     late-bound function references rather than methods and array-likes
>     instead of true arrays.
>         var push =,
>             arrayLike = Object.create(null);
>         arrayLike.length = 0;
>         push(arrayLike, 'item-1');
>     As long as the environment is correct when my script initializes,
>     I get all methods I need to use stored inside my library's
>     closure. Freezing isn't needed.
> That's correct. I've written a bit of code like that myself. At first, 
> for those used to JS or even just conventional oo, the style needed is 
> very counter-intuitive and awkward -- it goes against the grain of 
> what the language tries to make convenient. But amazingly, it is 
> possible, and one even gets used to it after a while.
Would it be easier to teach everyone to freeze their built-ins or to 
(re)write their code using this style?

> We need a name for your use case. It is definitely distinct from the 
> normal JS library writing practice, which implicitly assumes that the 
> primordials haven't been too corrupted but does nothing to detect if 
> this is true.
Given what you're describing as normal library writing practice, 
teaching everyone to freeze their built-ins sounds like a safer bet in 
the path of acceptability and making the web overall safer.

In my opinion, to a large extent, using a library and messing around 
with built-ins the library might be using is a recipe for disaster. This 
practice shouldn't be encouraged.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list