A methodology for testing web applications

Welcome to the third course of the cybersecurity track. You already know how networks, Linux and systems work. Now you will learn how to examine a web application the way a professional tester does: calmly, step by step, with a method and a notebook, never by guessing at random.

Why you need a method

Imagine a home inspector visiting a house. A bad inspector wanders around, opens a few doors and says “looks fine”. A good inspector follows a checklist: foundations, roof, wiring, plumbing, windows, locks. They write down what they checked, even when everything was fine, so that nothing is forgotten and the owner can trust the report.

Testing a web application works the same way. Applications are made of dozens of pages, hundreds of parameters and many hidden behaviours. Without a method you will test the three things you thought of and miss the fourth one that matters. With a method, you cover the surface systematically, and you can explain to someone else exactly what you did.

The OWASP Web Security Testing Guide

OWASP (the Open Worldwide Application Security Project) is a non-profit community that publishes free, vendor-neutral security resources at owasp.org. Two of its documents will accompany you throughout this course:

• The OWASP Top 10: a regularly updated awareness list of the most critical categories of web application risks. It tells you what tends to go wrong.
• The Web Security Testing Guide (WSTG): a detailed handbook describing how to test for each category. It is organised in chapters, each with individual test cases.

You do not need to read the WSTG cover to cover. Think of it as a reference book: you will come back to it whenever you start a new family of tests. What matters now is understanding the overall shape of a test.

The main phases of a web test

Different organisations name the phases differently, but the logic is always the same. Here is a simplified version that we will follow in this course.

Notice that reporting is a phase in its own right. A vulnerability that nobody understands is a vulnerability that nobody fixes. We will spend a whole chapter on it at the end.

Phase 1: scope and authorisation

Before touching anything, a professional tester obtains a document, often called the rules of engagement or the statement of work. It answers practical questions:

• Which targets? Which domains, applications and environments are in scope, and which are explicitly out of scope?
• Which techniques? Are denial-of-service tests forbidden? Can the tester create accounts? May they read real customer data if they stumble on it?
• When? Test windows protect the client’s operations and let their team tell a test from a real attack.
• Who to contact? If something breaks or a serious problem is found, a named person must be reachable.
• How is data handled? What happens to screenshots, captured traffic and credentials after the engagement?

The same principle applies to bug bounty programmes, where organisations publish a policy that invites researchers to look for flaws: the published policy is the scope. Anything outside it remains off limits. We will return to this in the last chapter.

Your testing notebook

Throughout this course you will audit a training application and keep a testing notebook. It can be a simple text file, a spreadsheet or a note-taking app. Each entry should record:

1. The date and what you were testing (a page, a feature, a parameter).
2. What you did, in enough detail that you could repeat it.
3. What you observed.
4. Your conclusion: vulnerable, not vulnerable, or unsure.

This habit will turn into the final audit report in chapter 7. Professionals say that a test which is not written down did not happen.

Date: 2026-03-02
Target: training application, login page (local lab)
Test: observe how the login form reacts to an empty password
Action: submitted the form with the password field empty
Observation: error message "Password required", HTTP status 200
Conclusion: expected behaviour, no issue

Black box, grey box, white box

Testers also distinguish how much they know in advance:

• Black box: you start with nothing but the address, like an outsider.
• Grey box: you get some information, typically one or two user accounts. This is the most common and efficient setup, because it lets you test what an ordinary logged-in user could do.
• White box: you also receive the source code and architecture documents, which allows the deepest review.

In our training labs you will usually work in grey box mode: you know the application is vulnerable on purpose, and you have the test accounts.

Testing is not attacking

A subtle but important point: the goal of a test is to demonstrate that a weakness exists with the least possible impact, not to do as much damage as possible. A tester who proves that an admin page is reachable does not delete data. A tester who finds a way to read another user’s record shows one harmless example and stops. This “minimal proof” attitude protects the client, protects you, and makes your report more credible.

Your turn: write your own scope

Create your testing notebook and write the first page: a scope statement for your future lab. Include the target (a training application you will install in lesson 3), the allowed techniques, the machine it runs on, and the rule that you will never point your tools at anything else.

SCOPE - personal training lab
Targets: one training web application running on my own machine, reachable only from my computer
Out of scope: any other website, network or device, including my home router and other people's machines
Allowed: all test types covered in this course, since the application is deliberately vulnerable
Forbidden: testing anything on the internet, sharing the vulnerable application outside my machine
Evidence: notes and screenshots stored in this notebook
Reminder: no written authorisation = no test

In the next lesson you will set up the tool that sits at the heart of web testing: an intercepting proxy.