I saw Alex Sexton give a talk called "Client-side Security Stuff" at Austin JavaScript tonight.

You guessed it! It was about JavaScript security! I'll jump to the end and tell you that in summary that as he put it "There's no hope. You can always..." and thus you'll have to decide for yourself what you want to prioritize. He gave the Adam Sontag quote "There ain't no party, like a third party." in regards to web sites which loop in third party content inside of an iFrame, such as the Facebook like button, and cautioned that the .postMessage cross-talk across two domains can get really nasty and lead to collisions with other JavaScript at the "first" party (if you will) web presence. He works at a company called Stripe which has faced such a challenge and he recommends creating your own middleman page to serve up into your own iFrame. The middleman page will itself have an iFrame and that iFrame will hit the third party. Now we have a third level for our third party. The barrier minimizes crosstalk contamination. John-David Dalton recommends this sort of sandboxing. This was the very first thing in the talk and it set the stage for what was to come in that it was esoteric. At one point the template/XSS thing was discussed, but most of the attacks that were laid out were more colorful and things I had not heard of before. Interesting acronyms I had not heard before were:

• HSTS (HTTP Strict Transport Security) may be added to an HTTP header (it's one line in the header) to force the content to display in https or not at all.
• CSP (Content Security Policy) is a spec for security. This suggests that everything be locked down to a point wherein a site may only display HTML and then, from that point expanding beyond this baseline, other things that are needed are progressively whitelisted to be looped in as deemed to be likely not sinister. The BATSHIELD (Back-Acronymed Trustworthy Secure Helper Internet-Enabled Lightweight Defense) is a way to make CSP happen. There is also a CSP2 wherein there will be a hash in the header of a page and a hash at a script tag and if the two hashes do not play nicely with each other then the script tag will not run. This helps to neutralize injected script tags.
• SRI (sub resource integrity) is a second security spec. This has to do with the dependency chain that materializes when you call a script that calls other scripts and does something-er-other to make those murky waters shallow so that you can't drown in them. (My analogy could be better.)

So what were some of the attacks mentioned? (attacks I've not heard of before)

• You should use CORS instead of JSON-P (JSON with padding) as all JSON-P is doing behind the scenes is creating a script tag and dropping it at the URL. This is hackable. The XHR request approach of CORS is less flimsy. See: enable-cors.org
• With CSS alone one can do something called Link Knocking. Just as CSS may be used to determine visited links from not yet visited links (purple versus blue, right?) one may somehow use this trick to get a list of not yet visited links in the immediate history. There are ways to brute force a list of Google URLs out of this gunk into what someone had searched at Google before they landed at the sinister web site. The Engagency peeps so interested in implicit data of visitors would love to have this sort of information, right? You could run an algorithm against it to judge what sort of cruise a visitor to a travel site might be interested in and then bait them with the right ad to get them to fill out a form so you could move on to the explicit data profile of the visitor.
• There is a way to lay an SVG filter over an iFrame, max out its contrast so that every pixel appears as either pure black or pure white, push that to a canvas, save out an image from the canvas, and then run OCR (optical character recognition) against the image to read text out of any web site that may be hosted in an iFrame.
• A guy named "Samy" wrote evercookie which takes existing cached temp data and casts it to every possible storage means imaginable. localStorage, sessionStorage, and a bunch of other shapes of this ilk all get the data and thus a security hole is ballooned. The only way to beat all of the dissemination to elsewhere that this does is to only use Safari and to restart it completely whenever changing sites.