I was reading this really cool article on Chlorine Trifluoride, which apparently can basically burn through just about anything, including sand, asbestos tile, glass, and probably even leftover high school cafeteria pizza.  I completely love this description:

It is, of course, extremely toxic, but that's the least of the problem. It is hypergolic [ignites on contacts - ed with AP chemistry] with every known fuel, and so rapidly hypergolic that no ignition delay has ever been measured. It is also hypergolic with such things as cloth, wood, and test engineers, not to mention asbestos, sand, and water-with which it reacts explosively.

Speaking of Explosive

We have been spending a lot of time looking at SEO tools while deploying some of our own (Yahoo Store SEO Analyzier, Digg Friend Finder, Backlink Pinger) and while we've talked a lot about SEO Application Architecture we never did much writing about security.  I guess we thought that with all the, er, black hat stuff that can go on around this industry that people would be careful about how their SEO applications were architected.

Uh, No

Without naming names, though you'd recognize them as very big players, we found dozens of security holes in their applications, including but not limited to:

• Wide Open Ajax Services - Ajax is a wonderful thing. And FireFox protects the browser against cross site scripting. But if the service on the back end is willing to accept a call from anything and doesn't verify that it's the client that's actually calling, then someone else can write an application that does the same thing you do, but uses your server to do the work. For example, another server running PHP could use curl to load one of your pages and then make web service calls to your "public" service and you'd be hard pressed to tell. You'd think you were getting lots of traffic, but you'd just be providing the back end for someone else.
• Javascript Based Security - It's hard to believe, but we've seen plenty of applications that take a login in javascript, make an Ajax call to authenticate, and then enable a button or show content using javascript. If some hacker couldn't figure out how to rape and pillage those systems I think they'd get kicked out of their club.

About That Picture

That is a picture of a couple of pounds of Chlorine Trifluoride going off inside an asbestos berm test container. Or it is your website as some hacker takes control of your PR checker (for example) and hoses down google with it until they block your IP or penalize your site?

Ouch.

Perils of Outsourcing

Of the dozen or so tools we found with major security flaws the most common theme was not age of deployment, or country, or sophistication of the tool.  It was that the development was outsourced by a very non technical person.  Not non-technical as in "doesn't understand SEO" or "can't figure out how to tickle google" but as in: not much exposure to complex software engineering.

One thing you should know: we have some extremely technical people on staff.  (Not me, I just fetch the coffee.)  I think we could probably safely outsource applications built to a safe and sophisticated  architectural specification, but it'd be tricky.

We described our SEO architectural technical stack earlier, but here it is again:

Here is my rule of thumb: if you can't understand that picture, you can't export the work.  You need someone working for you who "gets" it.  I'm not bragging - we're not perfect and there are a lot of things (*cough* graphic design *cough*) that we don't do very well and have to get help with.

Conclusion

If you are going to outsource some development and you'd like to avoid a meltdown, well, you should probably get someone on staff or at least locally consulting with you to ensure that you have proper security. If you can't look at the code that your overseas outsourcing partner is giving you and make sense of it, then you probably shouldn't be trying to play that game.