Rodney Rehm

The Problematic Source

To many people this looks like valid code - in its current form »it just works«™:

Escaping Strings For Use In HTML

The most important, yet not very obvious, issue is escaping special characters. You know that <, >, &, " and ' have a special meaning in HTML. <> delimit tags, " and ' delimit attribute values, & is the lead-in of entities.

What do you think would happen to '<img title="' + image.title + '">' were some content author to set image.title = '"dancing unicorns" by Someone Special';? exactly, the resulting HTML string would look like <img title=""dancing unicorns" by Someone Special"> - obviously invalid markup. Things break, they break fast. The problem gets worse if content authors and developers aren't the same person - and they never are!

Aside from the risk some random team member might venture outside the scope of alpha-numeric characters, this also presents a security vulnerability. Someone with malicious intent might be able to inject some funky code into your page - something you really want to prevent by all means.

Javascript - the feature-poorest language since brainfuck - does not have a function to escape these special characters (not yet at least). Javascript developers are used to doing things themselves, over and over again. The following snippet is such a thing:

Introducing this homebew html-escaper to our image-creator, we end up with:

Not very nice, but at least we've managed to kill the stability and security concerns.

Using jQuery

What we can do manually with escapeHtml(), we can also let jQuery (the DOM, actually) do for us. jQuery.attr() wraps element.setAttribute. This is a DOM method, not a string wrangler. This method knows that the output is meant for the DOM and thus handles escaping special characters internally (figuratively speaking). jQuery, being the spectacular API it is, allows us to rewrite our image-creator to something safer and more readable:

Paying close attention to the code you've probably seen some optimization potential. image already is a map, why not simply pass that?

But, but, now there's an img attribute on the <img> element. Could that mean that our content authors could add arbitrary attributes like image.whosDaBoss = "me me me!";? Well, yes, sadly this can happen - and as you know Murphy's Law: whatever can happen, will happen. So how can we prevent undesired attribtues from being set?

Underscore, a functional library you really should have a closer look at, provides the function _.pick. The function walks maps (objects, dictionaries, hashes, whatever the cool kids call it today) and only returns the properties you wanted:

If you're not already using Underscore and have no need for any of its (quite helpful) functions, you can implement pick() yourself:

Learning By Teaching

Writing this article opened the door for others to comment. @bassistance pointed out that jQuery takes a second argument - a map of attributes - that eliminates the need for the .attr() call. Putting this into action:

Conclusion

• Be wary of context switches like text -> html, always escape everything
• Remember that the data you're handling is not your domain, it might change without you being informed
• Use jQuery's powerful API
• Use Underscore, lot's of helping stuff in there

Next to neglected string escaping, unfamiliarity with jQuery (any library, actually) is something I see (and experience myself) every day. If this is happening to you, too, try setting up a »read the docs day« for your team. The gist is that every developer has to look up (and actually read) the docs of every single function he uses that day. If you're a fun bunch, count the (numerous) »oooh, I didn't know XYZ could do that?!« developers mumble into their beards that day. The one who's learnt the most gets a free beer (or ten).