Security testing requires thinking out of the box, it noes not have clear test cases, and it is not repeatable, meaning running same set of actions over and over again will never assure security.

So I wonder, how to plan it? Isn't it better just to give a tester time for hacking a site, and then record vulnerabilities?

Is it reasonable to require a detailed security test plan and what to include to it?

5 Answers 5


First, your product probably has some kind of security-related provisions: e.g. authentication, authorization, password recovery, prevent one user from seeing another user's data, and so on. There will be positive and negative test cases for those.

Beyond that is the more complicated stuff. There are tools available for scanning websites for security problems (e.g. Nessus), and you should plan to use them. There are companies who will do security testing for you. They may use those same tools and/or employee hackers who specialize in this kind of thing. This is a very specialized discipline, and most QA folks don't have the skills or the up-to-date knowledge to do a thorough job at it.

The answer also depends on the risks of someone breaking into your site.


The above answers are correct, and depending on the importance of the security, you are probably best advised to get some security experts in.

Other than that, in order for you to have a go yourself, some useful resources I use to dabble in security testing / ethical hacking are :

"How to break web software" James Whittaker

I practice on googles gruyere & on friends websites to provide them feedback on their security - You can find some interesting holes, which really aren't that well hidden.


I am not a security tester, however, your test planning will vary depending on whether you need to maintain the secure status of the web application, or whether you are doing a one-off "this application is secure" set of tests.

In both cases, I do think you need to plan - but for one-off test sets you don't need to plan for repeatability.

I'd look at classes of common vulnerabilities and potential harm, and use a matrix of these to prioritize tests: starting with common, high damage potential scenarios and working through to the less damaging, then less common scenarios.

Your plan here should be a living document - a template of techniques to use to try to break the security of the application. That way, you don't accidentally overlook something in your testing, and your test cases document the methods you used and the results you received.


I would probably look at STRIDE and allocate a given time to each of the threat areas, the duration that is allocated however, will be determined by the skill and experience of the tester.

If there aren't any experienced security testers in the team then you probably wont get any really value from doing this in house, it really is a specialist area. You can risk assess each of the threat areas and accept the risk depending on the outcome.


I have a similar question with an idea rather than an answer. I am beginning testing on a website and starting security soon as well. My understanding is that it is almost better to have a set of "exploratory" testing points rather than step by step processes to test.

For instance:

- attempt html code
- attempt SQL injection

Address bar
- reach root directory
- edit files contained within parent directory

This allows a tester to have the freedom to "try" hacks that not everyone is aware of. This is extremely dependant on a testers experience. With that being said, where would someone get a list of known "hacks"? Or how does someone list "hacks" or methods of hacking for examination? This information isn't just listed somewhere for testers to "examine" correct?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.