Getting Started with Web Application Security Testing

Web applications are the most exposed attack surface of any modern organisation. From e-commerce platforms to banking portals, if it runs in a browser, it can be hacked. This guide walks you through real-world web application security testing methodologies using industry-standard tools and techniques.

Understanding the OWASP Top 10

The OWASP Top 10 is the baseline for every web security tester. These are the most critical security risks to web applications. As of 2026, the key categories include:

• Broken Access Control — Users accessing resources they should not have permission to
• Cryptographic Failures — Weak or missing encryption for sensitive data
• Injection — SQL, NoSQL, OS command, and LDAP injection flaws
• Insecure Design — Architecture-level security gaps
• Security Misconfiguration — Default credentials, unnecessary features enabled
• Vulnerable Components — Outdated libraries and frameworks
• Identification & Authentication Failures — Weak login mechanisms
• Data Integrity Failures — Insecure deserialization, software supply chain
• Logging & Monitoring Failures — No visibility into attacks
• SSRF — Server-side request forgery

Setting Up Your Testing Environment

Before you test anything, you need a controlled environment. Never test against targets without explicit written authorisation.

bash$ docker run --rm -it -p 80:80 vulnerables/web-dvwa
$ docker run --rm -it -p 3000:3000 bkimminich/juice-shop

Reconnaissance: Mapping the Attack Surface

Every good test starts with recon. Before firing off exploits, understand what you are dealing with.

Passive Reconnaissance

Gather information without touching the target server directly:

• WHOIS Lookup — Find domain registration details
• DNS Enumeration — Discover subdomains and exposed services
• Google Dorking — Find exposed files, directories, and error messages

bash$ whois example.com
$ dig example.com ANY +short
$ host -t ns example.com

Active Reconnaissance

Actively probe the target to discover open ports, running services, and hidden paths:

bash$ nmap -sV -sC -p- target.com -oN scan.txt
$ gobuster dir -u https://target.com -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
$ ffuf -u https://target.com/FUZZ -w /usr/share/wordlists/discovery/subdomains.txt -H "Host: FUZZ.target.com"

Nmap with -sV performs service version detection, while -sC runs default safe scripts. Gobuster and FFuF are essential for content discovery.

Intercepting Traffic with Burp Suite

Burp Suite is the industry standard for web application testing. The Community Edition (free) includes everything you need to get started.

Configuring the Proxy

1. Open Burp Suite and go to the Proxy tab
2. Set the proxy listener to 127.0.0.1:8080
3. Configure your browser to use 127.0.0.1:8080 as an HTTP/HTTPS proxy
4. Install Burp's CA certificate in your browser to intercept HTTPS traffic

Once configured, every request between your browser and the target flows through Burp. You can intercept, modify, and replay requests.

Testing for SQL Injection

SQL injection remains one of the most dangerous web vulnerabilities despite being well understood. Here is how to test for it systematically.

Manual Detection

Start with simple payloads in every user input field:

sql'
' OR '1'='1
' UNION SELECT null, username, password FROM users --
1' ORDER BY 1--
1' ORDER BY 2--
1' ORDER BY 3--

Look for error messages, changes in behaviour, or unexpected data disclosure. A single quote (') that triggers a database error is a strong indicator.

Automated Detection with SQLMap

SQLMap automates the detection and exploitation of SQL injection flaws:

bash$ sqlmap -u "https://target.com/page?id=1" --batch --dbs
$ sqlmap -u "https://target.com/page?id=1" -D database_name --tables
$ sqlmap -u "https://target.com/page?id=1" -D database_name -T users --dump

Testing for Cross-Site Scripting (XSS)

XSS allows attackers to inject malicious scripts into web pages viewed by other users. There are three main types:

• Reflected XSS — Payload is in the URL/request and reflected immediately
• Stored XSS — Payload is stored on the server (comments, profiles, etc.)
• DOM-based XSS — Payload executes via client-side JavaScript manipulation

Testing Payloads

html<script>alert('XSS')</script>
<img src=x onerror=alert('XSS')>
<svg onload=alert('XSS')>
<input onfocus=alert('XSS') autofocus>
<details open ontoggle=alert('XSS')>

Enter these payloads into form fields, URL parameters, and search boxes. If you see a JavaScript alert dialog, XSS is confirmed.

Testing Authentication & Session Management

Weak authentication is one of the easiest ways into an application. Test these scenarios:

• Default credentials — Try admin:admin, admin:password, test:test
• Username enumeration — Use different error messages for valid vs invalid usernames
• Session fixation — Can you set a victim's session ID to a known value?
• Insecure cookie flags — Check if cookies have HttpOnly, Secure, SameSite flags
• Brute force protection — Test if account lockout or rate limiting is in place

bash$ hydra -l admin -P /usr/share/wordlists/rockyou.txt target.com http-post-form "/login:user=^USER^&pass=^PASS^:Invalid"

Testing for Broken Access Control

Access control flaws allow users to perform actions beyond their privilege level:

• IDOR (Insecure Direct Object Reference) — Change /profile?id=123 to /profile?id=124
• Privilege Escalation — Modify a hidden field like <input type="hidden" name="role" value="user">
• Directory Traversal — Try ../../etc/passwd in file download parameters

Writing the Report

A security test is only as good as the report. Every finding should include:

• Title — Clear, descriptive vulnerability name
• Severity — Critical / High / Medium / Low / Info
• Description — What the vulnerability is and why it matters
• Steps to Reproduce — Concise, repeatable steps with screenshots
• Impact — What an attacker could achieve
• Remediation — Specific fix recommendations

Next Steps

Web application security testing is a skill that improves with practice. Start with the labs mentioned above, work through CTF challenges on FoxFoster CTF Arena, and consider pursuing the Burp Suite Certified Practitioner or OSCP certifications for formal validation of your skills.

Visit FoxFoster Labs for hands-on web security practice environments, and join our community to discuss findings and techniques with fellow security researchers.