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.
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.
Doesn't work. I add the webscan.html file then scan again and get an empty response every time. URL is https://www.webscanservice.com/index.php/startscan as well I don't know if that's correct or not.
Not sure why it's front page and getting upvoted when it doesn't do anything at all. Seems like a good idea though if it works, curious to see what sort of things it checks for.
Happy to see more people who care about security. We run a seemingly similar service, although I can't seem to get this one working. I'd definitely check out other ways of verifying the domain though, since this leaves all your customers open to the Google Hacking of searching for webscan.html for sites a hacker can toss through your system.
Yes. Just wait some minutes. I guess the server is under heavy load.
Got some false positives though. For example "PHP Admin Application" and "PHP Debug Application" for files <root>/admin.php and <root>/debug.php which both do not exist actually.
I wasn't able to try yet because of the required file but it looks cool so far. So far I'd suggest letting people know they need to add the webcam file first. Or if that's already there make it more prominent as its not really obvious. I'm checking it out on my iPad, maybe the desktop version makes that point clearer.
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.