DEV Community

loading...
Cover image for How to mess up your JavaScript code like a boss

How to mess up your JavaScript code like a boss

Jan Küster
Graduated in Digital Media M.Sc. now developing the next generation of educational software. Since a while I develop full stack in Javascript using Meteor. Love fitness and Muay Thai after work.
・14 min read

Photo by Sebastian Herrmann on Unsplash

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!?
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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'
  }
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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]"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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!
Enter fullscreen mode Exit fullscreen mode
  • 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!
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Finally:

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

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"
Enter fullscreen mode Exit fullscreen mode

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
}
Enter fullscreen mode Exit fullscreen mode
  • 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
Enter fullscreen mode Exit fullscreen mode
  • 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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

let n = 1
n.toString(2) // "1"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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)
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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++
  }
}
Enter fullscreen mode Exit fullscreen mode

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++
  }
}
Enter fullscreen mode Exit fullscreen mode

13. 🔥 Other problematic stuff

Discussion (1)

Collapse
ogrotten profile image
ogrotten

Like A boss?

Or like THE boss?