Principles of Security. Douglas Crockford, Yahoo! Senior JavaScript Architect.

White hats vs black hats. Security is not hats. Security specialization is a problem. Security cannot be delegated to someone in a hat. Security is everyone’s job, don’t leave it to specialists.

The web turned from document retrieval system to application delivery system, but the web was not refactored. Not unusual for purpose of software to change over its life but this left open security holes in the web.

Deterrence is not effective. You can’t punish an invisible attacker. Making an attacker fearful does not work online. You cannot threaten a bot. Prevention is the only thing that works.

Johann Martin Schleyer, creator of Volapuk in 1880. Aimed to be a one world language and had the chance to take over the world unlike any other language. The thought was that Europe would always be at war due to different languages. A common language would put an end to the war.

Jean Guillaume Auguste Victor Francios Hubert Kerckhoffs found the good parts and bad parts of Volapuk and also published La Cryptographie Militaire in 1883, assuming there would be electronic communication. His work is still in use in today’s communication systems.

De-babelization turned into re-babelization. Tolkein described language creation as a secret vice.

The design of a system should not require secrecy. Compromise of the system should not inconvenience the correspondents. – The Kerchhoffs’ Principle

Kerchoff said the only secret in the encryption machine should be the key. The more secrets you have, the harder they are to keep. There is no security in obscurity.

A ”one time pad” is truly unbreakable:

  • Key must always remain secret
  • Key must be at least as long as the plain text
  • Cypher text is obtained by XORing of the plain text and the key
  • The key must be perfectly random
  • A key must never be used more than once

Attacker is most likely to attack at weakest point, not your strongest.

Cryptography is not security.

Security must be factored into every decision. ”We’ll go back and make it secure later” is a common mistake. The most difficult part is the security and it should be built into the design. You can’t add security, you can only remove insecurity. You can’t add reliability, you can only remove unreliability.

Having survived to this point does not guarantee future survival. Having not been hacked does not guarantee you won’t be hacked.

The impossible is not possible. If a measure is not effective, it is ineffective. There is no point in preventing anything that cannot be prevented. Don’t prohibit what you can’t prevent. Exploit what you cannot prevent.

False security is worse than no security because it causes you to make bad decisions. If you think you have no security you will be cautious, if you think you’re secure when you’re not, you will be reckless.

The browser is horribly insecure. We’re still “fixing it later”. HTML5 made it worse instead of better but it’s still better than the alternatives.

We’re left with blame the victim security models by asking users “security” questions to give cover to incompetent security developers.

Who’s interest does the program represent? The browser got this right but every other platform got this wrong. The website represents the interests of the website, not the user. The browser recognized that.

What the web got wrong

  • More interests involved than simply just the users and the sites
  • A malicious party can exploit coding conventions to inject malicious code
  • Malicious code gets all rights of the site - XSS problem

Sites that unexpectedly ask for password at random times for “security” train the user to give up the password at will.

Cross site scripting (XSS) can be useful. It is good for mashups and is not inherently bad. XSS attacks were invented in 1995 and we have made no progress on the fundamental problems since then. A mashup is a self inflicted XSS attack. Advertising is a mashup–interests of advertiser mixed with interests of the site. The most reliable, cost effective method to inject evil code is to buy an ad.

Why is there XSS? The web stack is “too complicated”. Too many languages with their own encoding, quoting, commenting, escapement conventions. Since each can be nested inside each other, browsers do heroic things to make sense of malformed content. Template based web frameworks are optimized for XSS injection.

Attackers make good use of browser flexibility and interpretation of bad coding and markup.

JavaScript global objects are available to every script on the page and every scrap of script the same powerful capabilities. As bad as it is, still better than the alternatives.

The browser distinguishes interests of user and site but did not anticipate multiple interests. Within a page, interests are confused. An ad or widget or AJAX library gets same rights.

JavaScript got close to getting it right and can be repaired, becoming an object capability language.


  • Grants power to confusers
  • Easily confused
  • Is forgiving because web developers were/are incompetent

The browser API, the DOM, is insecure. If you get access to any node in the DOM you get access to any element in the DOM and access to the root, which gives you access over the page.

Any unit of the software should be given only the capabilities it needs to do its work and no more. – Principle of Least Authority

Comes from the actor model in 1973, informed by early work on Smalltalk. Actors scale very big and small and come with amazing security by default.


  • Computational entity
  • Sends messages to other actors only if it knows their addresses
  • Cannot guess address
  • Can create new actors locally
  • Can receive messages

Web workers are actors. Web services are not actors because they have publicly known URLs. - applies the actor model to web services through distributed, reliable services.

Capabilities of an Actor

  • An address of an actor is a capability
  • A reference to an object is a capability

If references can only be obtained by creation, construction, or introduction, you may have a safe system. Capabilities should be granted on a need-to-do basis. If any object is corrupted, the corruptor only gets access to the capabilities the object has

The lazy programmers’ guide to secure computing by Marc Stiegler

Confusion aids the enemy. If the language is only good parts, it is more secure. With great complexity comes great confusion.

Never trust a machine that is not under your absolute control. Don’t get more intimate than JSON payloads.

Never trust the browser. It cannot and will not protect your interest. Properly filter and validate all input. Properly encode all output. Context is everything. Filter and encode for correct context.

To prevent concatenation attacks, use proper encoders like json.stringify. Don’t build strings by concatenation because it makes it too easy for attackers to insert attacks.

Inconvenience is not security. Identity is not security. Taint ain’t security. Intrusion detection is not security.

Mismanagement is the biggest source of insecurity. Security needs to be responsibility of everyone not just people in “hats”.

Slides and full video from talk available from Chariot Solutions.