When you use `for...in` over a plain object, which keys can show up that you never put on that object, and how do you filter them out?

## What for...in reaches `for...in` does not enumerate an object; it enumerates a *chain*. Starting at the object, it visits each enumerable string-keyed property, then moves to the object's prototype and does the same, and so on to the end of the chain — skipping any name it has already yielded, so a shadowed key appears once. Symbol keys are never included, and non-enumerable properties are never included. For a plain literal that is usually invisible, because everything on `Object.prototype` (`toString`, `hasOwnProperty`, `valueOf`, …) is defined as non-enumerable: ```js const o = { a: 1, b: 2 }; for (const k in o) console.log(k); // a, b — nothing else ``` ## Where the surprise keys come from **A custom prototype.** The most direct case: ```js const proto = { shared: 'yes' }; const obj = Object.create(proto); obj.own = 1; for (const k in obj) console.log(k); // own, shared ``` **Assignment onto a prototype.** Properties created by plain assignment are enumerable by default, so this leaks: ```js function Point(x) { this.x = x; } Point.prototype.describe = function () { return `x=${this.x}`; }; for (const k in new Point(1)) console.log(k); // x, describe ``` Note that methods defined with `class` syntax are non-enumerable, so a `class Point { describe() {} }` does **not** leak `describe` into `for...in`. That asymmetry between the two ways of writing the same class trips people up. **Built-in prototype extension.** The historical worst case: a script does `Array.prototype.last = function () {...}` or `Object.prototype.each = ...`, and now every `for...in` anywhere in the program yields an extra key. This is why defensive `hasOwnProperty` guards litter older codebases. ## The guard, and why the obvious spelling is unsafe The modern form is `Object.hasOwn`, added in ES2022: ```js for (const k in obj) { if (!Object.hasOwn(obj, k)) continue; // ... own keys only } ``` Before ES2022 the correct spelling was the call form: ```js if (!Object.prototype.hasOwnProperty.call(obj, k)) continue; ``` That call form exists for two concrete reasons, and being able to name them is what separates a memorised idiom from understanding: 1. **Null-prototype objects.** `Object.create(null)` produces an object with no prototype at all — a common choice for dictionaries precisely because nothing is inherited. It therefore has no `hasOwnProperty` method, so `obj.hasOwnProperty(k)` throws a `TypeError`. 2. **Shadowing.** If the data itself contains a key named `hasOwnProperty` — entirely possible when the object came from parsed JSON or user input — then `obj.hasOwnProperty` is that data, not the method, and calling it fails or lies. `Object.hasOwn(obj, k)` sidesteps both, which is exactly why it was added. ## The better default: skip for...in Almost every loop that needs a `hasOwn` guard would be clearer written with an own-keys helper and `for...of`: ```js for (const k of Object.keys(obj)) { /* own enumerable string keys */ } for (const v of Object.values(obj)) { /* their values */ } for (const [k, v] of Object.entries(obj)) { /* both */ } ``` All three return arrays containing only **own**, enumerable, string-keyed properties — the inherited-key problem simply does not arise, and you get real array methods (`map`, `filter`, `sort`) for free. Because they are arrays you can also `break` out of the `for...of`, which is a bonus over `forEach`. The cases where `for...in` is genuinely the right tool are narrow: you actually want inherited enumerable properties, or you are working with an object whose keys you cannot materialise into an array for memory reasons. Both are rare. ## A note on completeness None of these — `for...in`, `Object.keys`, `Object.values`, `Object.entries` — see symbol keys or non-enumerable properties. If you need everything an object owns, that is what `Object.getOwnPropertyNames` and `Object.getOwnPropertySymbols` are for. Reaching for those is a signal you are doing reflection rather than ordinary data iteration.