[tptacek]

I can see you're not really selling to an informed audience (and that's fine!) but I really think you want to sacrifice some of the Google-like simplicity of your front page to explain what, exactly, you're testing on target sites.

Some reasons to at least give broad strokes about how you're testing:

(i) Testing for some kinds of web flaws is inherently intrusive; for instance, it's very hard to reliably test for stored XSS without potentially disrupting an application for users.

(ii) Aggressive spidering will create performance issues for some clients, and "oh well you should have known better" isn't going to stanch the PR bleeding when you take someone's site down.

(iii) If you're doing authz testing, you will eventually find a site where a post-auth crawl will delete huge swaths of database entries because someone implemented "delete" as a vanilla GET link.

(iv) (To me, the most important) Lots of uninformed clients will run something like this and feel confident they've checked the "security" part of their deployment checklist; without knowing exactly what you're testing for (and ideally being up front about the things you don't test for), you can give clients a really dangerous false confidence.

[jay_l]

I agree with this. I think many users won't be willing to go through with the verification step unless they have some clue about what this site actually does.

After all, you're targeting users who, even if they aren't incredibly informed, at least have enough technical savvy to be running a site.

[Natsu]

You're absolutely right. It's important for people to know what you're testing. Point (iii) in particular is all too real:

http://thedailywtf.com/Articles/The_Spider_of_Doom.aspx