That's what the original poster is saying, yes. JS does not support a formal separation between the 'attributes' and 'keys' of a hash, so it's a security risk waiting to happen.

In some cases the JS approach is very nice and useful: in Python you see gobs and gobs of classes used to hold data structures, mostly because people don't seem to like dicts in general. I remember a talk, but not the speaker or title of it, where it was pointed out that your Python class is probably a dict plus a function if it has exactly two methods, one of which is called __init__. Python being what it is, you may also extend Python to do what JS does, but slightly more intelligently:

    class obj(dict):
        def __init__(self, vals={}):
            for key in vals:
                self[key] = vals[key]
        def __setattr__(self, name, value):
            self[name] = value
        def __getattribute__(self, name):
            try:
                return dict.__getattribute__(self, name)
            except AttributeError:
                if name in self:
                    return self[name]
                else:
                    raise AttributeError("'obj' has no key '%s'" % name)

This lets you use dotted setters/getters with Python without accidentally having x['keys'] = 1 override the obj.keys() method (which it inherits from dict). It's a serious problem in real Python code I've read and written; you create 'classes' which are only instantiated once (and are therefore semantically dicts). So the JS model really has some advantages for easy, clear namespacing (and packaging and enumeration) of identifiers, but yes, there is a potential security question if you allow people to set or get arbitrary JS attributes.