Web Application Hacking — OWASP Top 10, XSS, CSRF, and Burp Suite
What Is Web Application Security and Why Does It Matter?
Section titled “What Is Web Application Security and Why Does It Matter?”The OWASP Top 10 (2021) is the industry-standard awareness document for the most critical web application security risks, and the SANS/CWE Top 25 Most Dangerous Software Weaknesses provides a complementary, data-driven ranking of the vulnerabilities most commonly exploited in real-world attacks. Together, these frameworks define the baseline knowledge every web security professional needs.
Web application security is the practice of identifying and fixing vulnerabilities in web applications before attackers exploit them. With over 70% of breaches involving a web application component, understanding how web apps are attacked is one of the most valuable skills in cybersecurity today.
Modern organisations run their entire operations through web applications — banking, healthcare, e-commerce, government services. Every login form, search bar, and file upload is a potential entry point for attackers. If you understand how these attacks work, you can help defend against them.
When I first encountered the OWASP Top 10, I felt overwhelmed. Ten categories of vulnerabilities, each with sub-types and edge cases — it seemed like an impossible amount to memorise. Then I realised that most web app attacks come down to the same fundamental problem: the application trusts user input without validating it. Once I understood that core principle, everything else started falling into place. XSS? Untrusted input rendered as HTML. SQL injection? Untrusted input executed as a database query. CSRF? The server trusts that every request from your browser was intentional.
Certification objectives: CompTIA Security+ SY0-701 covers web application attacks including injection, XSS, and CSRF. CEH v13 dedicates multiple modules to web application hacking methodology, OWASP Top 10, and tools like Burp Suite.
What Do Real-World Web Application Attacks Look Like?
Section titled “What Do Real-World Web Application Attacks Look Like?”The Verizon 2024 DBIR found that web application attacks were the most common attack pattern across all industries, accounting for a significant portion of confirmed data breaches. MITRE ATT&CK catalogues web application exploitation techniques under T1190 (Exploit Public-Facing Application), one of the most frequently observed initial access methods.
Web applications are the most exposed part of any organisation’s attack surface. These are the problems attackers exploit daily.
| Problem | What goes wrong | Real-world impact |
|---|---|---|
| Untrusted user input | Application processes user-supplied data without validation or sanitisation | Injection attacks (XSS, SQLi) steal data or hijack sessions |
| Broken authentication | Weak password policies, missing MFA, session tokens that never expire | Account takeover, credential stuffing attacks compromise thousands of accounts |
| Excessive permissions | Users can access resources or functions beyond their authorised scope | Broken access control — the #1 OWASP category since 2021 |
| Security misconfiguration | Default credentials, verbose error messages, unnecessary features enabled | Attackers gain footholds through debug endpoints or exposed admin panels |
| Outdated components | Third-party libraries and frameworks with known CVEs remain unpatched | Supply chain attacks exploit vulnerable dependencies at scale |
| Missing server-side validation | Client-side checks are the only defence, easily bypassed with a proxy | Price manipulation, privilege escalation, data exfiltration |
Understanding these problems is essential for anyone entering cybersecurity — whether you end up in penetration testing, security operations, or application security.
What Are the Key Concepts Behind Web Application Security?
Section titled “What Are the Key Concepts Behind Web Application Security?”The OWASP Application Security Verification Standard (ASVS) provides a comprehensive framework for testing web application security controls, while the CWE/MITRE database catalogues over 900 individual software weakness types — with injection (CWE-79 for XSS, CWE-89 for SQLi) and broken access control (CWE-284) among the most prevalent.
Think of a web application like a restaurant. The dining area is the client side (your browser) — customers can see the menu and place orders. The kitchen is the server side — where the real work happens. The waiter carrying orders back and forth is the HTTP request/response cycle.
Web application attacks happen when a customer slips instructions to the kitchen that the waiter was never supposed to deliver. Maybe the customer writes “and give me every other customer’s order” on the back of their order slip. If the kitchen follows those instructions without checking, that is an injection vulnerability.
The OWASP Top 10 (2021)
Section titled “The OWASP Top 10 (2021)”The OWASP (Open Worldwide Application Security Project) Top 10 is the industry-standard awareness document for web application security. It represents the most critical categories of web application vulnerabilities.
| Rank | Category | What it means | Example |
|---|---|---|---|
| A01 | Broken Access Control | Users can act outside their intended permissions | Modifying a URL parameter to access another user’s account |
| A02 | Cryptographic Failures | Sensitive data exposed due to weak or missing encryption | Passwords stored in plain text, HTTP used instead of HTTPS |
| A03 | Injection | Untrusted data sent to an interpreter as part of a command or query | SQL injection, XSS, command injection, LDAP injection |
| A04 | Insecure Design | Fundamental flaws in the application’s design and architecture | No rate limiting on password reset, missing fraud controls |
| A05 | Security Misconfiguration | Default settings, incomplete setup, overly permissive configurations | Default admin credentials, directory listing enabled, stack traces in errors |
| A06 | Vulnerable and Outdated Components | Using libraries or frameworks with known vulnerabilities | Running an unpatched version of Log4j, jQuery, or WordPress plugins |
| A07 | Identification and Authentication Failures | Broken authentication mechanisms | Permitting weak passwords, missing MFA, session fixation |
| A08 | Software and Data Integrity Failures | Code and infrastructure that does not verify integrity | Unsigned updates, CI/CD pipeline poisoning, deserialisation attacks |
| A09 | Security Logging and Monitoring Failures | Insufficient logging to detect or respond to attacks | No audit logs, alerts not triggered on suspicious activity |
| A10 | Server-Side Request Forgery (SSRF) | Application fetches a remote resource without validating the user-supplied URL | Attacker forces the server to make requests to internal services |
Key Attack Types Explained
Section titled “Key Attack Types Explained”Cross-Site Scripting (XSS) occurs when an application includes untrusted data in a web page without proper validation or escaping. There are three types:
- Reflected XSS — malicious script is reflected off the server in an error message, search result, or URL parameter. The payload comes from the current HTTP request.
- Stored XSS — malicious script is permanently stored on the target server (in a database, comment field, or forum post). Every user who views the page executes the script.
- DOM-based XSS — the vulnerability exists in the client-side JavaScript code itself, which modifies the page DOM using untrusted data.
Cross-Site Request Forgery (CSRF) forces an authenticated user’s browser to send a forged request to a vulnerable application. If you are logged into your bank and visit a malicious page, that page could submit a hidden form that transfers money — because your browser automatically sends your session cookie with the request.
Broken Access Control is when users can access resources or perform actions they should not be authorised for. This includes horizontal privilege escalation (accessing another user’s data) and vertical privilege escalation (performing admin functions as a regular user).
Note: SQL injection is covered in detail on its own dedicated page — SQL Injection. This page focuses on the broader web application attack surface.
Step-by-Step: Web Application Testing Methodology
Section titled “Step-by-Step: Web Application Testing Methodology”Ethical hackers follow a structured methodology when testing web applications. This is the same approach used in professional penetration tests and bug bounty programs.
Step 1 — Reconnaissance: Gather information about the target application. Identify the technology stack (web server, framework, programming language), map out pages and endpoints, and discover hidden content.
Step 2 — Mapping the application: Crawl the application to build a complete sitemap. Identify all input points (forms, URL parameters, headers, cookies), authentication mechanisms, and access control boundaries.
Step 3 — Vulnerability discovery: Systematically test each input point for common vulnerabilities. Test for injection (XSS, SQLi, command injection), broken authentication, access control flaws, security misconfigurations, and business logic errors.
Step 4 — Exploitation: Attempt to exploit discovered vulnerabilities to demonstrate real-world impact. This proves the vulnerability is not just theoretical — it has practical consequences for the organisation.
Step 5 — Post-exploitation: Determine what an attacker could achieve after initial exploitation. Can they pivot to other systems? Access sensitive data? Escalate privileges?
Step 6 — Reporting: Document every finding with clear steps to reproduce, evidence (screenshots, request/response pairs), severity ratings, and remediation recommendations.
Legal warning: Never test web applications without explicit written authorisation. Unauthorised testing is illegal in Australia under the Criminal Code Act 1995 (Cth) and equivalent state legislation. Always use dedicated practice environments like DVWA, WebGoat, or TryHackMe labs.
Architecture — How Web Application Attacks Fit Into the Security Picture
Section titled “Architecture — How Web Application Attacks Fit Into the Security Picture”Web Application Attack Methodology
Section titled “Web Application Attack Methodology”📊 Visual Explanation
Section titled “📊 Visual Explanation”Web Application Testing Methodology
The structured approach ethical hackers use to find and report vulnerabilities
Burp Suite vs OWASP ZAP
Section titled “Burp Suite vs OWASP ZAP”📊 Visual Explanation
Section titled “📊 Visual Explanation”Burp Suite vs OWASP ZAP
- Industry standard — Used by most professional pentesters and bug bounty hunters
- Paid licence (Community edition is free) — Professional edition costs ~$449/year
- Powerful scanner — Best-in-class automated vulnerability scanning
- Extensive extensions — BApp Store with hundreds of community plugins
- Better for professionals — Required skill for penetration testing careers
- Completely free and open source — No cost — ideal for students and career changers
- Active community project — Maintained by OWASP with regular updates
- Good automated scanner — Solid scanning capabilities, slightly behind Burp Pro
- Built-in automation — Excellent for CI/CD pipeline integration
- Better for learning — Great starting tool before investing in Burp Suite
Burp Suite Core Components
Section titled “Burp Suite Core Components”Understanding Burp Suite’s key tools is essential for any aspiring penetration tester:
| Component | Purpose | When to use it |
|---|---|---|
| Proxy | Intercepts HTTP/HTTPS traffic between browser and server | Every test — this is your primary view into application traffic |
| Scanner | Automated vulnerability scanning (Professional edition) | After manual mapping, to catch vulnerabilities you might have missed |
| Repeater | Manually modify and resend individual requests | Testing specific parameters, crafting payloads, confirming vulnerabilities |
| Intruder | Automated payload delivery (fuzzing, brute force) | Password attacks, parameter fuzzing, testing multiple payloads |
| Decoder | Encode/decode data in various formats (Base64, URL, HTML) | Decoding obfuscated data, encoding payloads to bypass filters |
| Comparer | Side-by-side comparison of requests or responses | Spotting differences in responses that indicate a vulnerability |
Practical Examples — Testing for Common Web Vulnerabilities
Section titled “Practical Examples — Testing for Common Web Vulnerabilities”Practice safely: Use these techniques only on applications you own or have permission to test. DVWA, WebGoat, and TryHackMe provide legal practice environments.
Example 1: Testing for Reflected XSS
Section titled “Example 1: Testing for Reflected XSS”<!-- Basic XSS test payload — enter this in search fields and URL parameters --><script>alert('XSS')</script>
<!-- If the application reflects this without encoding, you have found XSS -->
<!-- Common bypass when angle brackets are filtered -->" onmouseover="alert('XSS')" "
<!-- Testing with event handlers when script tags are blocked --><img src=x onerror="alert('XSS')">
<!-- Check if the payload appears in the page source unencoded --><!-- View Source (Ctrl+U) and search for your payload -->Example 2: Browser Developer Tools for Security Testing
Section titled “Example 2: Browser Developer Tools for Security Testing”# Open Developer Tools in any browser: F12 or Ctrl+Shift+I
# Network tab — inspect every HTTP request and response# Look for: sensitive data in URLs, missing security headers, API endpoints
# Console tab — test for DOM-based XSS# Try: document.cookie (if accessible, HttpOnly flag is missing)
# Application/Storage tab — examine cookies and local storage# Check for: session tokens without Secure/HttpOnly flags# Look for: sensitive data stored in localStorage (never safe)Example 3: Checking Security Headers with curl
Section titled “Example 3: Checking Security Headers with curl”# Inspect response headers for security configurationscurl -I https://example.com
# Key headers to look for:# Content-Security-Policy — prevents XSS by controlling script sources# X-Content-Type-Options: nosniff — prevents MIME type sniffing# X-Frame-Options: DENY — prevents clickjacking# Strict-Transport-Security — enforces HTTPS# X-XSS-Protection — legacy XSS filter (deprecated but still seen)
# Check for missing headers (these indicate potential vulnerabilities)curl -s -D- https://example.com -o /dev/null | grep -i "security\|content-security\|strict-transport\|x-frame\|x-content"Example 4: Setting Up Burp Suite Proxy
Section titled “Example 4: Setting Up Burp Suite Proxy”# 1. Download Burp Suite Community Edition from PortSwigger# 2. Configure your browser to use proxy: 127.0.0.1:8080# 3. Visit http://burp in your browser to download the CA certificate# 4. Install the CA certificate in your browser's certificate store# 5. Browse the target application — all traffic appears in Burp's Proxy tab
# Tip: Use Firefox with a separate proxy profile# This keeps Burp testing separate from your normal browsing
# FoxyProxy browser extension makes switching proxies easy# Configure one profile for "Burp Suite" pointing to 127.0.0.1:8080Trade-offs, Limitations, and Failure Modes
Section titled “Trade-offs, Limitations, and Failure Modes”Web application security involves constant trade-offs between usability, security, and development speed.
| Strength | Common failure mode | Better approach |
|---|---|---|
| Input validation prevents injection attacks | Client-side validation only — easily bypassed with a proxy | Always validate on the server side. Client-side validation is for UX only |
| Content Security Policy (CSP) blocks XSS | CSP is too permissive (allows unsafe-inline or unsafe-eval) | Start with a strict CSP and whitelist only necessary sources |
| Web Application Firewalls (WAFs) block known attacks | WAF rules are bypassed with encoding, obfuscation, or novel payloads | WAFs are a layer, not a solution. Fix the underlying code vulnerability |
| Automated scanners find common vulnerabilities | Scanners miss business logic flaws and complex multi-step attacks | Combine automated scanning with manual testing by skilled testers |
| HTTPS encrypts traffic in transit | Application still exposes sensitive data in URLs or JavaScript | Never put secrets in URLs. Use POST bodies and proper server-side storage |
The fundamental lesson: Security must be built into the application from the start, not bolted on after deployment. No tool or WAF can fully compensate for insecure code.
Entry-Level Interview Perspective
Section titled “Entry-Level Interview Perspective”Web application security is one of the most frequently tested areas in cybersecurity interviews, especially for SOC analyst and junior penetration tester roles.
| Question | What they are testing | Strong answer approach |
|---|---|---|
| What is the OWASP Top 10? | Awareness of industry standards | It is a regularly updated list of the 10 most critical web application security risks, maintained by OWASP. Broken Access Control has been #1 since 2021 |
| Explain Cross-Site Scripting (XSS) | Understanding of a core vulnerability | XSS occurs when an application includes untrusted data in a web page without validation. Explain the three types (reflected, stored, DOM) and that it allows attackers to execute scripts in victims’ browsers |
| What is the difference between XSS and CSRF? | Ability to distinguish related attacks | XSS exploits trust the user has in a website (injects malicious scripts). CSRF exploits trust the website has in the user’s browser (forges requests using the user’s session) |
| How would you test a web application for vulnerabilities? | Methodology and process | Describe the structured approach: reconnaissance, mapping, discovery, exploitation, and reporting. Mention tools like Burp Suite and OWASP ZAP |
| What is broken access control and why is it ranked #1? | Practical security awareness | Users can act outside their intended permissions — accessing other users’ data, modifying records, or performing admin functions. It is #1 because it is extremely common and directly leads to data breaches |
Real-World Security Operations — Australian Context
Section titled “Real-World Security Operations — Australian Context”Web application attacks dominate the Australian threat landscape. Understanding how SOC teams and regulators address them is critical for job readiness.
SOC perspective: Security Operations Centres monitor web application traffic using Web Application Firewalls (WAFs), SIEM log correlation, and anomaly detection. SOC analysts regularly investigate alerts for SQL injection attempts, XSS payloads in web logs, and brute-force login attempts. Understanding what these attacks look like in log files makes you immediately valuable in a SOC role.
ASD Essential Eight: The Essential Eight framework addresses web application security through several controls — application hardening (removing unnecessary features, disabling macros), patching applications (keeping web frameworks and libraries current), and restricting administrative privileges (limiting who can modify web application configurations). The ACSC ISM provides detailed guidance on web application security controls for Australian Government systems.
ACSC guidance: The Australian Cyber Security Centre publishes specific advisories about web application vulnerabilities. Their guidelines recommend implementing input validation, output encoding, parameterised queries, and least-privilege database accounts — all fundamental web application security controls.
Australian breach context: Major Australian breaches including Optus (2022), Medibank (2022), and Latitude Financial (2023) all involved web application or API vulnerabilities. These incidents led to significant regulatory reforms and increased focus on web application security in Australian organisations.
Practical advice for Australian job seekers: Demonstrate familiarity with the OWASP Top 10 and hands-on experience with tools like Burp Suite or ZAP. Mention the ASD Essential Eight when discussing how web application security fits into an organisation’s broader security posture. Employers value candidates who can connect technical vulnerabilities to business risk.
Summary and Key Takeaways
Section titled “Summary and Key Takeaways”Web application security is arguably the most important domain in modern cybersecurity — web apps are the primary attack surface for most organisations.
- The OWASP Top 10 is your essential reference. Broken Access Control is #1 because it is the most common and impactful category of web application vulnerability.
- Most web attacks exploit untrusted input. XSS, injection, and CSRF all succeed because applications fail to validate, sanitise, or escape user-supplied data.
- XSS has three types — reflected (from the current request), stored (persisted in the database), and DOM-based (client-side JavaScript vulnerability). Each requires different testing and mitigation approaches.
- CSRF exploits the trust a website has in the user’s browser. Anti-CSRF tokens and SameSite cookies are the primary defences.
- Burp Suite and OWASP ZAP are the two essential web application testing tools. Start with ZAP (free) and move to Burp Suite Professional for career advancement.
- Always follow a structured methodology: reconnaissance, mapping, discovery, exploitation, and reporting. This is how professional penetration testers work.
- Never test without permission. Unauthorised testing is illegal. Use practice environments like DVWA, WebGoat, and TryHackMe to build your skills safely.
Related
Section titled “Related”- SQL Injection for the detailed guide on SQL injection attacks and prevention
- Networking Basics for understanding HTTP, DNS, and the protocols web applications rely on
- Cryptography Basics for TLS, HTTPS, and how encryption protects web traffic
- CompTIA Security+ for how web application attacks appear on the certification exam
Frequently Asked Questions
What is the OWASP Top 10?
The OWASP Top 10 is a regularly updated awareness document listing the ten most critical categories of web application security risks. Published by the Open Worldwide Application Security Project (OWASP), it is the industry-standard reference for web application security. The current version (2021) places Broken Access Control at number one.
What is the difference between XSS and CSRF?
XSS (Cross-Site Scripting) exploits the trust a user has in a website by injecting malicious scripts that execute in the victim's browser. CSRF (Cross-Site Request Forgery) exploits the trust a website has in the user's browser by forging requests that use the victim's authenticated session. XSS attacks the user through the site. CSRF attacks the site through the user.
Is Burp Suite free?
Burp Suite Community Edition is free and includes the proxy, repeater, decoder, and comparer tools. Burp Suite Professional (approximately $449/year) adds the automated scanner, advanced intruder options, and additional features. The Community Edition is sufficient for learning, but most professional pentesters use the Professional edition.
What is broken access control?
Broken access control occurs when an application fails to properly enforce restrictions on what authenticated users are allowed to do. This includes horizontal privilege escalation (accessing another user's data by changing a parameter), vertical privilege escalation (accessing admin functions as a regular user), and direct object reference vulnerabilities.
How do I practise web application hacking legally?
Use dedicated vulnerable applications designed for practice: DVWA (Damn Vulnerable Web Application), OWASP WebGoat, OWASP Juice Shop, and platforms like TryHackMe and HackTheBox. Never test real websites without explicit written authorisation from the owner.
What is a Web Application Firewall (WAF)?
A WAF is a security control that monitors, filters, and blocks HTTP traffic to and from a web application. It protects against common attacks like SQL injection and XSS by inspecting requests against predefined rules. However, WAFs can be bypassed and should complement — not replace — secure coding practices.
Why is input validation so important?
Input validation is the first line of defence against injection attacks. When an application accepts user input without checking that it conforms to expected formats and values, attackers can inject malicious code. Server-side validation is essential — client-side validation can be easily bypassed using a proxy tool like Burp Suite.
What are security headers and why do they matter?
Security headers are HTTP response headers that instruct the browser to enable specific security features. Key headers include Content-Security-Policy (prevents XSS), Strict-Transport-Security (enforces HTTPS), X-Frame-Options (prevents clickjacking), and X-Content-Type-Options (prevents MIME sniffing). Missing security headers are a common finding in web application assessments.
Do I need to know how to code to test web applications?
Basic understanding of HTML, JavaScript, and HTTP is essential for web application testing. You do not need to be a professional developer, but you need to understand how web applications work, read source code to spot vulnerabilities, and craft payloads. Learning basic Python is also helpful for writing custom testing scripts.
Is web application security covered in Security+ and CEH?
Yes. CompTIA Security+ SY0-701 covers web application attacks including injection, XSS, CSRF, and secure coding concepts. CEH v13 dedicates several modules to web application hacking, including detailed coverage of the OWASP Top 10, Burp Suite, and web application testing methodology. Both certifications consider it an essential knowledge area.
More resources
The official OWASP Top 10 document — the industry-standard reference for web application security risks.
PortSwigger Web Security AcademyFree, comprehensive web application security training from the makers of Burp Suite. Includes interactive labs.
OWASP Testing GuideThe complete OWASP guide to web application security testing methodology and techniques.
Technical concepts verified in March 2026 against the OWASP Top 10 (2021), OWASP Testing Guide v4.2, PortSwigger Web Security Academy documentation, and the ACSC Essential Eight Maturity Model. Vulnerability descriptions and tool capabilities should be verified against current sources as the web application security landscape evolves rapidly. Career and salary data sourced from CyberSeek and BLS Occupational Outlook Handbook as of 2025. Individual results vary based on background, effort, and market conditions.