How to mess up your JavaScript code like a boss

This content originally appeared on DEV Community and was authored by Jan Küster

Good Bye, reliable code! Leverage these concepts and language features, deploy your app and then... watch everything burn ?

Quick access

1. Relying on typeof checks
2. Relying on instanceof checks
3. Mixing up direct with inherited properties
4. Relying on toString output
5. Using parseInt without radix
6. Introduce type coercion
7. Using truthy / falsy in branch evaluations
8. Using object bracket notation with user input
9. Validate numbers only half-way
10. Rely on Number arithmetic for floats
11. Use && or || in conditional returns
12. Rely on pseudo-private properties
13. Other problematic stuff

I actually felt that way from time to time when I just ran into some of these things the first time. It was like all my hard work had just been nullified by a simple misunderstanding or naive implementation. ?

This article is therefore my personal "best-of" collection of problems that came up due to my very naive usage of JavaScript. Some of them actually caused severe issues in my early days apps and brought me countless hours of debugging, reading, finding and fixing. ?

However, this process made me a better developer and engineer and I hope they will also serve for you and your projects well. Knowing them and finding alternatives at the design phase will improve your apps robustness and maintainability. At least I think so. Leave a comment, if think otherwise. ❤️

1. ? Relying on `typeof` checks

In JavaScript you are actually pretty lost, when you rely on checking the given type of a variable:

// expected
typeof 135.791113 // "number"
typeof "foo" // "string"
typeof {} // "object"
typeof Symbol('foo') // "symbol"
typeof 1357911n // "bigint"

// somewhat unexpected for beginners
typeof [] // "object", expected something like "array"
typeof async () => {} // "function", expected "async function"

// totally not as expected
typeof NaN // "number", what!? Not a number is a number!?
typeof null // "object", how can nothing be an object!?

Relying on typeof can therefore not be considered as safe, at least not without detailed additional checks. Relying on it in sensitive contexts can have severe consequences.

Involved issues

Runtime errors
Injection of unwanted code into functions can become possible
Breaking the applications or server process becomes possible

Potential fixes

Use a validation library (there are some, do your research)
Define "interfaces" (easy in TypeScript, though) that check for primitive (own) properties of an input
Extend your checks with additional checks (for example check if n is of type number and is not equal NaN
Add a lot more edge test-cases, use fuzzing techniques to make sure you cover as many non-trivial inputs as possible
Use TypeScript to have built-in type-checking at "compile time" (it's not a silver-bullet though)

2. ? Relying on `instanceof` checks

This is not only a problem from an OOP perspective (implement against interfaces, not classes!) but also does not work out quite well all the time:

// Proxy simply comes from another dimension....
new Proxy({}, {}) instanceof Proxy // TypeError: 'prototype' property of Proxy is not an object


// descendants of Object are still Objects
(() => {}) instanceof Object // true

// primitives disguising as Object
new String('foo') instanceof Object // true
new Number(1.357911) instanceof Object // true

// Object disguising as non-Object
Object.create(null) instanceof Object // false
const obj = {}
obj.__proto__ = null
obj instanceof Object // false

Involved issues

All of the former mentioned issues plus
Tight coupling is introduced easily

Potential fixes

All of the former mentioned fixes plus
Check for properties and their types instead of specific inheritance

3. ? Mixing up direct with inherited properties

The prototypical inheritance of JavaScript brings further complexity when it comes to detecting an Object's properties. Some have been inherited from the prototype, others are the object's own properties. Consider the following example:

class Food {
  constructor (expires) {
    this.expires = expires
    this.days = 0
  }

  addDay () {
    this.days++
  }

  hasExpired () {
    return this.days >= this.expires
  }
}

class Apple extends Food {
  constructor () {
    super(3) // 3 days
    this.shape = 'sphere'
  }
}

The `in` operator

Now let's create a new Apple instance and see which of the properties are available:

const apple = new Apple()

// let's add this method just to this one apple instance
apple.isFresh = () => apple.days < apple.expires

'expires' in apple // true
'shape' in apple // true
'addDay' in apple // true
'hasExpired' in apple // true
'isFresh' in apple // true

As you can see here we simply get true for every in check, because

The in operator returns true if the specified property is in the specified object or its prototype chain.
MDN

The `for...in` statement

Beware of confusing the in operator with the for..in statement. It gives you a totally different result:

for (const prop in apple) {
  console.log(prop)
}
// output
"expires"
"days"
"shape"
"isFresh"

The for..in loops only through the enumerable properties and omits all the methods, which are assigned to the prototype but it still lists the directly assigned properties.

The `hasOwnProperty` method

So it seems to be safe to always use for..in? Let's take a look at a slightly different approach to our food-chain:

const Food = {}
Food.expires = 3 // assigned, right!?

const apple = Object.create(Food)
apple.shape = 'sphere' // also assigned

'expires' in apple // true
apple.hasOwnProperty('expires') // false

'shape' in apple // true
apple.hasOwnProperty('shape') // true

for (const prop in apple) {
  console.log(prop)
}
// output
"expires"
"shape"

The apple is now created with Food as it's prototype, which itself has Object as it's prototype.

As you can see the expires property hasn't been passed down the prototype chain as it happened with the ES6 classes example above. However, the property is considered as "enumerable", which is why it's listed in the for..in statement's output.

Involved issues

Validations can fail, creating false-positives or false-negatives

Potential fixes

Make it clear, whether validations will check for direct properties or have look at the full prototype-chain
Avoid inheritance where possible and use composition in favor
Otherwise try to stick with ES6 classes as they solve many fiddling with the prototype chain for you

4. ? Relying on `toString` output

The toString method is a builtin that descends from Object and returns a String-representation of it. Descendants can override it to create a custom output that suits it's internal structure.

However, you can't simply rely on it without knowing each specific implementation. Here is one example, where you might think you are clever by using the toString method to fast-compare two Arrays:

[1, 2, 3].toString() === ["1",2,3].toString() // true, should be false

0.0.toString() === "0.0" // false, should be true

Also note, that someone can easily override global toString implementations:

Array.prototype.toString = function () {
  return '[I, am,compliant, to, your, checks]'
}

[1, 2, 3].toString() // "[I, am,compliant, to, your, checks]"

Involved Issues

Runtime errors, due to wrong comparisons
toString spoofing / overriding can break these checks and is considered a vulnerability

Potential fixes

Use JSON.stringify + sorting on arrays
If JSON.stringify alone isn't enough, you may need to write a custom replacer function
Use toLocaleString() or toISOString() on Date objects but note they are also easily overridden
Use an alternative Date library with better comparison options

5. ? Using `parseInt` without radix

There are builtin Methods, that help to parse a variable into a different type. Consider Number.parseInt which allows to parse a (decimal) Number to an integer (still Number).

However, this can easily get out of hand if you don't determine the radix parameter:

// expected
Number.parseInt(1.357911) // 1
Number.parseInt('1.357911') // 1
Number.parseInt(0x14b857) // 1357911
Number.parseInt(0b101001011100001010111) // 1357911

// boom
const hexStr = 1357911.toString(16) // "14b857"
Number.parseInt(hexStr) // 14

const binStr = 1357911.toString(2) // "101001011100001010111"
Number.parseInt(binStr) // 101001011100001010111

// fixes
Number.parseInt(hexStr, 16) // 1357911
Number.parseInt(binStr, 2) // 1357911

Involved issues

Calculations will end up wrong

Potential fixes

Always use the radix parameter
Only allow numbers as input, note that 0x14b857 and 0b101001011100001010111 are of type number and due to the 0x and the 0b prefixes the parseInt method will automatically detect their radix (but not for other systems like octal or other bases)

6. ? Introduce type coercion

You can easily write code that may bring up unexpected results if you don't care about potential type coercion.

To understand the difference to type conversion (which we discussion by one example in the previous section), check out this definition from MDN:

Type coercion is the automatic or implicit conversion of values from one data type to another (such as strings to numbers). Type conversion is similar to type coercion because they both convert values from one data type to another with one key difference — type coercion is implicit whereas type conversion can be either implicit or explicit.

The easiest example is a naive add-Function:

const add = (a, b) => a + b
add('1', 0) // '10'
add(0, '1') // '01'
add(0) // NaN, because Number + undefined  = NaN
add(1, null) // 1, just don't think about why...
add(1, []) // "1", just don't think about why...
add(1, []) // "1", just don't think about why...
add(1, () => {}) // "1() => {}", I'll stop here

Involved issues

Totally uncontrollable results will happen
Can break your application or server process
Debugging back from errors to the function where the coercion happened will be lots of fun... ?

Potential fixes

validate input parameters

const isNumber = x => typeof x === 'number' && !Number.isNaN(x) // unfortunately NaN is of type number 

const add = (a, b) => {
  if (!isNumber(a) || !isNumber(b)) {
    throw new Error('expected a and b to be a Number')
  }
  return a + b
}

add('1', 0) // throws
add('0', 1) // throws
add(0) // throws
add(1, null) // throws
add(1, []) // throws
add(1, []) // throws
add(1, () => {}) // throws
add(1, 2) // 3, yeay!

explicit conversion before coercion can happen

// preventing NaN by using parameter defaults
const add = (a = 0, b = 0) => {
  let a1 = Number.parseFloat(a, 10)
  let b1 = Number.parseFloat(b, 10)

  // a1, b1 could be NaN so check them
  if (!isNumber(a1) || !isNumber(b1)) {
    throw new Error('Expected input to be number-alike')
  }

  return a1 + b1
}

add('1', 0) // 1
add('0', 1) // 1
add(0) // 0
add(1) // 1
add(1, null) // throws
add(1, []) // throws
add(1, []) // throws
add(1, () => {}) // throws
add(1, 2) // 3, yeay!

A note on TypeScript

Simply using typescript won't fix the issue:

const add = function (a:number, b:number) {
    return a + b
}

add(1, NaN) // NaN

You will therefore end up with one of the above strategies. Let me know if you came up with another strategy.

7. ? Using truthy / falsy in branch evaluations

const isDefined = x => !!x
isDefined('') // false, should be true
isDefined(0) // false, should be true

Involved issues

Runtime errors
Undefined application state
Potential security risk if user input is involved

Potential fixes

Avoid truthy/falsy evaluations and evaluate strict
Additionally: have high test coverage; use fuzzing; test for edge cases

Example:

const isDefined = x => typeof x !== 'undefined'
isDefined('') // true
isDefined(0) // true
isDefined(null) // true <-- uh oh

Finally:

const isDefined = x => typeof x !== 'undefined' && x !== null
isDefined('') // true
isDefined(0) // true
isDefined(null) // false

If you don't want to use the typeof check here, you can alternatively use x !== (void 0).

8. ? Using object bracket notation with user input

A very underrated issues arises, when accessing properties via Object-Bracket notation by user input.

This is, because bracket-notation allows us even to override properties of the prototype-chain like __proto__ or prototype and thus potentially affecting all Objects in the current scope.

With prototype pollution an attacker is able to manipulate properties in the prototype chain and exploit this fact to gain privileged access.

Consider the following example:

const user = { id: 'foo', profile: { name: 'Jane Doe', age: 42 }, roles: { manager: true } }

function updateUser(category, key, value) {
  if (category in user) {
    user[category][key] = value
  }
}

// good use
updateUser('profile', 'locale', 'de-DE')

// bad use
updateUser('__proto__', 'exploit', 'All your base are belong to us')

// consequence of this
const newObject = {}
newObject.exploit // "All your base are belong to us"

I admin this example is inherently dangerous as it contains so many problems but I tried to break it down to give you the idea how easily a prototype pollution can occur with bracket notation.

Involved issues

Exploitable vulnerability

Potential fixes

use explicit variable names

function updateUserProfile(category, key, value) {
  if (key === 'name') user.profile.name = value
  if (key === 'age') user.profile.age = value
}

use Object.prototype.hasOwnProperty to check

function updateUser(category, key, value) {
  if (Object.prototype.hasOwnProperty.call(user, category)) {
    user[category][key] = value
  }
}

updateUser('__proto__', 'exploit', 'All your base are belong to us')

const newObject = {}
newObject.exploit // undefined

use a Proxy Object

const forbidden = ['__proto__', 'prototype', 'constructor']
const user = new Proxy({ id: 'foo', profile: { name: 'Jane Doe', age: 42 }, roles: { manager: true } }, {
  get: function (target, prop, receiver) {
    if (forbidden.includes(prop)) {
      // log this incident
      return
    }
    // ... otherwise do processing
  }
})

function updateUser(category, key, value) {
  user[category][key] = value
}

updateUser('profile', 'locale', 'de-DE')
updateUser('__proto__', 'exploit', 'All your base are belong to us') // error

Note: libraries are not a silver-bullet here!

9. ? Validate numbers only half-way

We already covered the problems with 'number' types in previous sections:

const isNumber = n => typeof n === 'number'

isNumber(NaN) // true
isNumber(Number.MAX_VALUE * 2) // true
isNumber(Number.MIN_VALUE / 2) // true

However, there is much more to validating numerical input. Consider a few potential cases here:

value is expected to be integer but is a float
value is not a "safe" integer (max./min. supported Int value)
value is +/-Infinity but expected to be finite
value is beyond Number.MIN_VALUE
value is beyond Number.MAX_VALUE

The potential issues should be clear by now (unless you skipped the first couple of sections) so let's find a modular way to handle as many of these cases as possible.

Base check for value to be a `Number`

const isValidNumber = num => (typeof num === 'number') && !Number.isNaN(num)

const num = Number.parseFloat({}) // => NaN
isNumber(num) // false, as expected

We simply don't want "not a number" to be interpreted as a number, that's just insane.

Check for value to be a safe integer `Number`

export const isValidInteger = num => isValidNumber(num) && Number.isSafeInteger(num)

isValidInteger({}) // false
isValidInteger(Number.parseFloat({})) // false
isValidInteger(1.357911) // false
isValidInteger(1.0) // true
isValidInteger(1) // true

Note the edge case of 1.0 which is internally in JS treated as integer:

let n = 1
n.toString(2) // "1"

Check for value to be a safe (computable) `Number`

const isInFloatBounds = num => isValidNumber(num) && num >= Number.MIN_VALUE && num <= Number.MAX_VALUE

isInFloatBounds(Infinity) // false
isInFloatBounds(-Infinity) // false

// check for MAX_VALUE
isInFloatBounds(100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000) // true
isInFloatBounds(1000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000) // false

// check for MIN_VALUE
isInFloatBounds(0.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001) // true
isInFloatBounds(0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001) // false

Make sure the value is in between the usable range. Everything beyond that should be handled using BigInt or a specialized library for large Numbers.

Also note, that allthough these values are considered valid floats, you may still find odd interpretations:

const almostZero = 0.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001
isInFloatBounds(almostZero) // true
almostZero // 1e-323

const zero = 0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001
isInFloatBounds(zero) // false
zero // 0

Check is value is a valid float `Number`

export const isValidFloat = num => {
  if (!isValidNumber(num)) return false
  if (num === 0) return true // this is debatable
  return isInFloatBounds(num < 0 ? -num : num)
}

This section already reveals the next one: simply avoid any serious floating point computations with Number in JavaScript!

10. ? Rely on Number arithmetic for floats

In order to understand this section, let's read on the JavaScript Number implementation:

The JavaScript Number type is a double-precision 64-bit binary format IEEE 754 value, like double in Java or C#. This means it can represent fractional values, but there are some limits to what it can store. A Number only keeps about 17 decimal places of precision; arithmetic is subject to rounding. The largest value a Number can hold is about 1.8E308. Numbers beyond that are replaced with the special Number constant Infinity.

Some examples, where this can become problematic:

Rounding issues

const n = 0.1 + 0.2 // 0.30000000000000004
n === 0.3 // false

Think of systems, where currencies are involved or calculation results are used for life-affecting decisions. Even the smallest rounding errors can lead to catastrophic consequences. ?

Conversion between number systems

Try to convert float to hex or to bin and back to float is not possible out-of-the box:

const num = 1.357911
const hex = num.toString(16) // 1.5ba00e27e0efa
const bin = num.toString(2)  // 1.010110111010000000001110001001111110000011101111101

Number.parseFloat(hex, 16) // 1.5
Number.parseFloat(bin, 2) // 1.01011011101

Working with large numbers is easily broken when using `Number`

// integers
const num = Number.MAX_SAFE_INTEGER
num       // 9007199254740991
num + 100 // 9007199254741092, should be 9007199254741091

// floats
const max = Number.MAX_VALUE
max           // 1.7976931348623157e+308
max * 1.00001 // Infinity

Potential solutions

Use BigInt
Use Math.fround
Use a library for precise arithmetic
Use typed arrays to precisely convert between numerical systems
Write your code in a way, that you can easily replace plain Number arithmetic with one of the above solutions

Note: I am not digging deeper into this as my best advice is to use a library that handles arithmetic precision for you. Doing your own implementations will easily still result in errors.

11. ? Use `&&` or `||` in conditional returns

This one is not definitive good or bad and rather depends on the situation. If you are certain, that the involved evaluations will always result in a boolean value then it it's safe to use them.

As example you can review the extended Number checks above. However, consider the following example: You want to write a function, that checks, whether a given array is filled.

const isFilled = arr => arr && arr.length > 0
isFilled([ ]) // false
isFilled([1]) // true
isFilled() // undefined

As you can see the function has not a well-defined return type. It should return either true or false but never undefined.

In these case you should write your code more verbose and explicit in order to make sure, that functions really return only valid values:

Possible solution

const isFilled = arr => arr ? arr.length > 0 : false
isFilled([ ]) // false
isFilled([1]) // true
isFilled() // false

Better

This solution is just a half-baked one, better is to throw an error to ensure the function had the proper input to reason about - fail early, fail often to make your application more robust:

const isFilled = arr => {
  if (!Array.isArray(arr)) {
    throw new TypeError('expected arr to be an Array')
  }
  return arr.length > 0
}

isFilled([ ]) // false
isFilled([1]) // true
isFilled() // throws Uncaught TypeError

Related issues

Ambiguous return values, leading to potential branching issues and runtime errors
Checks may fail
Business/application logic becomes unreliable

Potential fixes

Use ternary operator
return explicit
use TypeScript
Write extensive unit tests to ensure only valid return values are involved

12. ? Rely on pseudo-private properties

If you work a bit longer in the JavaScript realm you may still remember these "psuedo"-private members: if they begin with an underscore they are intended (by convention) to be private and not used directly:

const myObj = {
  _count: 0,
  count: function () {
    return count++
  }
}

Problems involved:

These properties are enumerable by default
They can be manipulated without any restrictions
By exploiting a prototype-pollution vulnerability they can theoretically be accessed by users; on the client they can be accessed anyway if the containing Object is accessible to the user

Potential fixes:

Use closures with real private variables

const createCounter = () => {
  let count = 0
  return {
    count: () => count++
  }
}

Use a Proxy Object to have fine grained control about any member access
Use classes with private features
Use my class-privacy if you can't support private members yet

13. ? Other problematic stuff

Using eval without exactly knowing what you're doing
Passing String literals to setTimeout (or setInterval)
rely on encodeURIComponent

This content originally appeared on DEV Community and was authored by Jan Küster

Print Share Comment Cite Upload Translate Updates

APA

Jan Küster | Sciencx (2021-07-27T08:53:31+00:00) How to mess up your JavaScript code like a boss. Retrieved from https://www.scien.cx/2021/07/27/how-to-mess-up-your-javascript-code-like-a-boss/

MLA

" » How to mess up your JavaScript code like a boss." Jan Küster | Sciencx - Tuesday July 27, 2021, https://www.scien.cx/2021/07/27/how-to-mess-up-your-javascript-code-like-a-boss/

HARVARD

Jan Küster | Sciencx Tuesday July 27, 2021 » How to mess up your JavaScript code like a boss., viewed ,<https://www.scien.cx/2021/07/27/how-to-mess-up-your-javascript-code-like-a-boss/>

VANCOUVER

Jan Küster | Sciencx - » How to mess up your JavaScript code like a boss. [Internet]. [Accessed ]. Available from: https://www.scien.cx/2021/07/27/how-to-mess-up-your-javascript-code-like-a-boss/

CHICAGO

" » How to mess up your JavaScript code like a boss." Jan Küster | Sciencx - Accessed . https://www.scien.cx/2021/07/27/how-to-mess-up-your-javascript-code-like-a-boss/

IEEE

" » How to mess up your JavaScript code like a boss." Jan Küster | Sciencx [Online]. Available: https://www.scien.cx/2021/07/27/how-to-mess-up-your-javascript-code-like-a-boss/. [Accessed: ]

rf:citation

» How to mess up your JavaScript code like a boss | Jan Küster | Sciencx | https://www.scien.cx/2021/07/27/how-to-mess-up-your-javascript-code-like-a-boss/ |

Please log in to upload a file.

There are no updates yet.
Click the Upload button above to add an update.

You must be logged in to translate posts. Please log in or register.

Quick access

1. ? Relying on typeof checks

Involved issues

Potential fixes

2. ? Relying on instanceof checks

Involved issues

Potential fixes

3. ? Mixing up direct with inherited properties

The in operator

The for...in statement

The hasOwnProperty method

Involved issues

Potential fixes

4. ? Relying on toString output

Involved Issues

Potential fixes

5. ? Using parseInt without radix

Involved issues

Potential fixes

6. ? Introduce type coercion

Involved issues

Potential fixes

A note on TypeScript

7. ? Using truthy / falsy in branch evaluations

Involved issues

Potential fixes

8. ? Using object bracket notation with user input

Involved issues

Potential fixes

9. ? Validate numbers only half-way

Base check for value to be a Number

Check for value to be a safe integer Number

Check for value to be a safe (computable) Number

Check is value is a valid float Number

10. ? Rely on Number arithmetic for floats

Rounding issues

Conversion between number systems

Working with large numbers is easily broken when using Number

Potential solutions

11. ? Use && or || in conditional returns

12. ? Rely on pseudo-private properties

Problems involved:

Potential fixes:

13. ? Other problematic stuff

Related Posts

1. ? Relying on `typeof` checks

2. ? Relying on `instanceof` checks

The `in` operator

The `for...in` statement

The `hasOwnProperty` method

4. ? Relying on `toString` output

5. ? Using `parseInt` without radix

Base check for value to be a `Number`

Check for value to be a safe integer `Number`

Check for value to be a safe (computable) `Number`

Check is value is a valid float `Number`

Working with large numbers is easily broken when using `Number`

11. ? Use `&&` or `||` in conditional returns