Cannot assign to read-only property (Property override mistake)

[kriskowal]

When you adopt or upgrade a library in a Hardened JavaScript project, you may encounter errors like:

TypeError#1: Cannot assign to read only property 'constructor' of object '[object Object]'

Or:

TypeError#1: Cannot assign to read only property 'toString' of object '[object Object]'

These are symptoms of the “property override mistake”.

Mitigation

There are many ways to mitigate these errors in your application. First, please let us know if you’ve found a new problem by leaving a comment on our ecosystem compatibility tracking issue.

If you’re in a rush, the fastest mitigation is to set the “override taming” to “severe”. If you’re handling the lockdown procedure directly, you can do that with an option.

lockdown({ overrideTaming: 'severe' });

In Node.js, lockdown will pick up LOCKDOWN_OVERRIDE_TAMING=severe from the environment.

> export LOCKDOWN_OVERRIDE_TAMING=severe

This also works on the web by setting up process.env.LOCKDOWN_OVERRIDE_TAMING = 'severe'.

If you’re using @endo/init to set up Hardened JavaScript, using @endo/init/legacy.js instead will set up severe override taming, but beware that it also disables error stack redaction and frame filtering.

Solution

You can help the Hardened JavaScript community patch any library that introduces a breaking change for Hardened JavaScript. We have had a fair amount of success getting packages to change.

Hello, we found that this library is not compatible with applications that freeze prototypes to defend against prototype pollution due to the JavaScript property override mistake. Would you accept a patch that changes object.constructor = constructor to Object.defineProperty(object, 'constructor', { value: constructor })?

Applications (but not libraries) can use patch-package to both mitigate the property override for their own use but also generate a patch to send the library’s authors.

Libraries do not benefit from patches because they have to be adopted at the level of an application’s lock-file. You can recommend that all users of a library adopt a patch, but all other usage will remain broken. For libraries, the same effect can only be obtained by getting the dependency to release a patch, or fork or subsume the dependency. Forking is a bridge too far for most libraries!

Prevention

We invite every JavaScript library to consider adding Object.freeze(Object.prototype) to the top of all their tests, with a comment pointing to this discussion. If especially generous, consider also freezing Function.prototype. This would serve as a highly reliable canary for compatibility with any technology that freezes prototypes to prevent prototype pollution mistakes or attacks. JavaScript may never be able to fix the prototype-override-mistake, but this one practice could obviate the harm it has caused.

Background

We like to think of Hardened JavaScript as the JavaScript that you already know. We treat shims as special and modifying prototypes you don’t own is otherwise taboo. Hardened JavaScript is just enforcement for this division. Any library designed for JavaScript also works under Hardened JavaScript. Almost.

Around 2009, the designers of JavaScript committed the “property override mistake”. If you freeze the prototype of an object, assigning a value to any property of the object that exists on its prototype will throw an exception. Consider:

Object.freeze(Object.prototype);
const object = {};
object.constructor = function () {}; // throws

This is almost never a problem because. All of the following cases work without issue:

Properties can be redefined if they are “configurable”.

Object.freeze(Object.prototype);
const object = {};
Object.defineProperty(object, 'constructor', {
  value: () => {},
});

Object literals are defined, not assigned.

Object.freeze(Object.prototype);
const object = {
  toString() {
    return 'Objekt';
  }
};

Classes are defined, not assigned.

Object.freeze(Object.prototype);
class Objekt {
  toString() {
    return 'Objekt';
  }
}

However, the modern idiom for overriding toString would be:

class Objekt {
  get [Symbol.toStringTag]() {
    return 'Objekt';
  }
}

JSON.parse defines properties and isn’t subject to the limitations of assignment.

Object.freeze(Object.prototype);
JSON.parse('{"constructor": {}}');

Objects with a null prototype aren’t subject to the configurability of properties on Object.prototype.

Object.freeze(Object.prototype);
const object = Object.create(null);
object.constructor = () => {};

And, object literals can be defined with a null prototype inline too.

Object.freeze(Object.prototype);
const object = { __proto__: null };
object.constructor = () => {};

There are cases that will break due to the property-override-mistake, but they’re outside what we would consider “The JavaScript you already know”. Objects should not be used as mutable maps. Assigning a key to of an object obtained by parsing user data is…fraught.

const object = JSON.parse(userData);
object[key] = value;

---

But a number of libraries, including some important and powerful libraries that are often tucked away in the transitive dependencies of many other libraries, assign to properties like constructor and consequently break under Hardened JavaScript. The second-most common errors from the property-override-mistake is assignment to toString. There are other cases but they are vanishingly rare.

Because of the property-override-mistake and because most JavaScript libraries do not test under Hardened JavaScript, a patch or feature release might be backward-compatible for JavaScript but be a breaking-change for Hardened JavaScript.

Known Compatibility Issues

We track Hardened JavaScript library compatibility in various places.

• Tracking issue for library compatibility issues Tracking issue for getting 3rd party packages more SES friendly #576
• General compatibility notes https://github.com/endojs/endo/wiki#compatibility-notes