Defensive JavaScript


That's a fine change, but you shouldn't remove the code that checks the inputs. TypeScript makes pragmatic assumptions so that, even when there are no type errors, a variable's value may not correspond to its type.

If you're not convinced ( or you're a fan of TS trivia :):

  • Shape facts defines a function that returns a number, except when an attacker abuses it to load arbitrary code.
  • Type confusion defines a "trusted" type class, but TypeScript doesn't catch type violations.
  • “A very simple piece of code” invites you to try to figure out how to attack a piece of JS that is still vulnerable when types are added.

Layer defenses

I used XSS throughout as an example of a security problem since developers are familiar with it, but some might say

Why should I worry about XSS? I use a strong Content-Security-Policy.

I wouldn't say "I'm wearing a hardhat so I don't need safety goggles." When you layer defenses, in this case Content-Security-Policy and safe coding practices, an attacker has to bypass both to affect your users.

Ask for help

Computer security is its own field with its own weighty textbooks, so don't expect to learn everything.

We security hat wearers may seem a tad paranoid, but we're really friendly people, so don't hesitate to reach out.

There are plenty of places to find help. For example:

If there's any that you found particularly helpful, mention them in the comments.

Finally, if you do want to try on a security hat, "Puzzling towards security" is a video series where I present a series of JS related capture-the-flag style puzzles, and I'm inviting attackers to test a hardened Node.js stack.

Thanks for reading :)