How a web application security test works

A web application security test is a structured look at an application you are allowed to test, with the goal of finding weaknesses before someone else does and helping the team fix them. It is not about breaking things for fun. It is a professional activity with a clear purpose, a defined scope and a written result.

The four parts of every test

1. Permission and scope. Before you send a single request, you need written authorisation from the owner of the application, naming the exact hosts, environments and dates. In this course you will only test applications that you run yourself on your own machine, such as OWASP Juice Shop, which exist precisely for training.
2. Understanding the application. You explore it like a curious user: every page, form, API call, role and workflow. Most findings come from understanding how the application is supposed to work.
3. Testing against known risk categories. You check each area against a recognised list, mainly the OWASP Top 10 and the more detailed OWASP Web Security Testing Guide (WSTG), using a mix of manual testing and careful automation.
4. Reporting and fixing. You write each finding so a developer can reproduce it, understand the impact and fix it, and then you retest.

Why a method matters

Without a method, testing turns into random clicking and running a scanner. Scanners are useful, but they miss whole classes of problems, especially access control and business logic flaws, which are exactly the problems that cause the most damage. A method makes sure you cover the same ground every time and can explain what you did and did not test.

Manual and automated work together

• Automated scanning with ZAP finds common, pattern based issues quickly: missing headers, some injection points, known vulnerable components.
• Manual testing with an intercepting proxy such as ZAP or Burp Suite Community Edition lets you change requests, switch users and test the rules that only a human can understand.

What you will build

Across the course you will set up a local practice lab, map a deliberately vulnerable application, test it against the main OWASP risk categories, and write a short professional report with findings, severity ratings and fixes. The same workflow applies to authorised work on real applications later, always with written permission first.