Like other whitepapers that have been put together by Adobe, Macromedia, Allaire, and others, this one offers overviews of key concerns along with proposed best practices.

Is it complete? Does it really need to be?

As with any such document, there will be debate among some readers about whether the practices are always really the "best". It's inevitable. But let's give credit that the authors do try to give a rather brief round up of the features, their options, and the impact of choices.

Just as Ben's famous CF "Certification Study Guide" is a quick summary of key things in CFML (and no substitute for the complete ColdFusion documentation or the WACK books), so too would I argue that this guide is a quick summary of important points to consider. Readers would do well to understand the issues completely, both in terms of the generic concerns they raise and the specifics of CFML features and options. For that, the docs and other books would be great resources.

Still, many readers won't have time for that, so despite the fact that some may pick it apart, it will serve a large percent of the community who might otherwise have no knowledge of the concerns and configuration features. For that, we should thank the authors.

Its sections

The document is divided into the following sections: Authentication, Authorization, CFCs, Session Management, Data validation and interpreter injection, Ajax, PDF integration, .NET integration, HTTP, FTP, Error handling and logging, File System, Cryptography, Configuration, Maintance and References.

Earlier editions, and what's updated in the CF8 guide?

While the guide does focus on CF8, there is another version of the document for those running CF7, the "ColdFusion 7 developer security guidelines". It, too, is by 2 of the 3 authors of the other whitepaper, Erick Lee and Sarge Sargent. It's only 33 pages, and it too is listed at the Adobe DevNet Security Developer Center, where it show it having been updated as of Oct 2007.

You might think that the CF8 guide is updated only to refer to things new in CF8, but in fact I find some things in the CF8 guide that are not in the CF7 guide, but are not new for CF7. Perhaps they decided to expand the CF8 guide in ways that they didn't push back down into the CF7 guide (understandable if time was limited). That means that CF7 developers may want to read the later guide, though they'd have to ignore features that are indeed new to CF8.

For instance, I found a discussion of the trusted cache feature only in the CF8 guide (more on that below). I didn't do a careful comparison of what's different.

BTW, I'll add that I found references in searches both on the Adobe site and Google to a version of the security guidelines at a URL that no longer works. Since I couldn't access it, I was unable to determine how this CF7 version was updated (or if it was simply renamed, to distinguish it from the new CF8 version. Perhaps the authors can comment here if they read this entry.)

Where to offer feedback?

That last comment brings up a concern I have with the whitepapers offered on the Adobe site (and the articles offered on the Developer Center, as well, of which I've been an author recently.) There's no place for folks to leave feedback. It would be nice for there to be a place to have discussions about the things written in such whitepapers or articles. (The Devnet articles do offer a feedback link, but it's one way, not an open discussion.)

I'm sure some will want to comment on or trade best practices regarding the topics in this paper. Also, I'd like to share at least one error I found: in the discussion of the trusted cache feature, it's described as, "Enable Trusted cache in production environments. When enabled, ColdFusion will only server requested templates held in its memory cache. This provides performance gains but also prevents ColdFusion from running hacked or invalid templates."

Yikes. I wonder who wrote that (and who missed it during any review).That's not the purpose of trusted cache at all. It's about whether the server should look to disk to see if a template, once compiled and loaded into memory, has changed on disk. The server always only serves (not the typo, too, "will only server") pages held in its memory cache. Using trusted cache is certainly a performance gain, but I really have no idea what the reference is to "hacked or invalid templates". That makes me think the person writing this has a very wrong idea about the feature. But I'm not meaning to rip the guidelines. As I said earlier, I'm sure that many will find them very useful, and since folks rarely read the docs, it's a nice way to condense into 40+ pages some key points. I'll let others comment here about any other concerns they have. At least it will serve as one place to have such discussion. If there's a better place, I'll welcome people pointing to that.