This article is Day 11 of a 100-day cybersecurity course, establishing foundational knowledge of web application architecture, HTTP protocol mechanics, and the attack surface before students advance to practical penetration testing tools. It addresses the critical gap that most security practitioners lack deep technical understanding of how web applications work at the protocol level, despite web vulnerabilities being the source of the majority of real-world breaches and bug bounty findings. The article matters because it provides the prerequisite knowledge required to understand and exploit vulnerability categories in the OWASP Top 10 and to use tools like Burp Suite effectively in subsequent lessons.
Key insights
Client-Server Three-Tier ArchitectureModern web applications operate on a three-tier model: Tier 1 (client/browser with attack surfaces in DOM and client-side scripts), Tier 2 (web server/application processing logic with vulnerabilities in input validation and authentication), and Tier 3 (database with SQL/NoSQL injection risks). The article emphasizes that most critical vulnerabilities target Tier 2, where user input directly meets server-side processing, making the application layer the primary testing focus.
HTTP Request Structure and SecurityEvery HTTP request contains multiple security-critical fields: the Cookie header carries session tokens whose theft enables account takeover, the Content-Type header determines how the server parses data and can be manipulated to bypass filters, and the Authorization header contains API tokens. Each field in both headers and request body represents a potential injection point that attackers can manipulate, making understanding the raw HTTP format essential before using tools like Burp Suite.
HTTP Response Headers as Security IndicatorsSecurity headers in HTTP responses directly impact exploit feasibility: missing X-Frame-Options enables clickjacking, absent Content-Security-Policy makes XSS more exploitable, missing Strict-Transport-Security allows SSL stripping attacks, and the Server header presence enables version fingerprinting. The article notes that checking which security headers are present takes 30 seconds with curl and represents a low-effort assessment finding, though such findings rarely pay in bug bounties.
Session Cookies and State ManagementHTTP is stateless, so cookies and sessions add state by having servers track session IDs and browsers automatically send them with every request. Cookie security flags each serve specific purposes: HttpOnly prevents JavaScript from reading cookies (blocking XSS-based session theft), Secure restricts transmission to HTTPS only, and SameSite=Strict prevents cross-site request forgery. A missing HttpOnly flag allows attackers to inject JavaScript that sends the victim's session cookie to an attacker-controlled server.
JWT Tokens and Algorithm ConfusionJSON Web Tokens use base64-encoded headers, payloads, and cryptographic signatures. The article demonstrates a classic JWT vulnerability where changing the algorithm from 'HS256' to 'none' and removing the signature can allow privilege escalation from user to admin role if the server accepts the 'none' algorithm. JWT vulnerabilities are consistently found in bug bounty programs, making understanding token structure essential for API testing.
Same-Origin Policy and CORS MisconfigurationThe Same-Origin Policy prevents JavaScript from reading data across different schemes, hostnames, or ports. CORS headers intentionally relax this policy; a misconfigured server using Access-Control-Allow-Origin: * combined with Access-Control-Allow-Credentials: true allows any website to make credentialed requests and read responses—a common bug bounty finding worth $500–$5000. This can be tested with curl by sending requests with arbitrary Origin headers and checking if they are reflected in the response.
OWASP Top 10 2021 and 2025 UpdatesBroken Access Control ranks as the #1 OWASP risk because it is pervasive, difficult for automated scanners to detect, and commonly missed in code review—requiring human understanding of application context to identify that a user should not access another user's data. The 2025 edition moves Security Misconfiguration to A02, adds Software Supply Chain Failures as A03, and folds SSRF into Broken Access Control, reflecting evolving real-world threat patterns.
Web Application Attack Surface MappingProfessional testing begins with systematic reconnaissance: technology fingerprinting using curl headers and tools like Wappalyzer, subdomain and endpoint discovery using ffuf against wordlists, input point inventory by browsing all forms and parameters, authentication surface analysis covering login mechanisms and password reset flows, and JavaScript analysis for hardcoded keys or hidden endpoints. This mapping phase precedes any payload testing and shapes the testing strategy.
Bottom line: Understanding HTTP protocol mechanics, cookie/session handling, JWT structure, and the three-tier application architecture is the foundation for all subsequent web application testing; without this knowledge, practitioners cannot effectively use tools like Burp Suite or comprehend vulnerability categories. Broken Access Control is the #1 OWASP risk precisely because it requires human understanding of application context that automated scanners cannot replicate, making manual security testing ess
🌐 PHASE 2 OF 5 — WEB APPLICATION SECURITY (DAYS 11–35)
You’ve completed Phase 1 — the foundation. Now we go deep into the most targeted category in security testing: web applications.
Over the next 25 days we cover the complete OWASP Top 10, Burp Suite mastery, SQL injection, XSS, authentication bypass, and bug bounty methodology. Today’s lesson is the foundation all of that sits on — how web applications actually work, and where every vulnerability category originates.
11
The vast majority of critical vulnerabilities found in security assessments and bug bounty programmes live in web applications. Not in the network. Not in the operating system. In the web application — the layer that most developers build, most organisations deploy, and most security teams least understand at a deep technical level.
Before you can find SQL injection, XSS, or authentication bypass — before Burp Suite makes complete sense — you need to understand how web applications work at the protocol level. That’s today. By the end, you’ll see every web page you visit differently.
Web application security is the broadest and deepest area in our entire 100-day course. We’re spending 25 days on it because it deserves that time. More penetration testing engagements focus primarily on web applications than on any other attack surface. More bug bounty findings come from web vulnerabilities than any other category. More real-world breaches originate from web application weaknesses than from anything else.
Client-Server Architecture — The Foundation of Every Web Application
Every web application is built on a client-server model. Your browser (the client) requests content from a server. The server processes the request and sends back a response. This exchange is mediated by HTTP — the protocol we covered in Day 5. What changes in Day 11 is the depth at which we understand each component.
Modern Web Application — Three-Tier Architecture
💻
TIER 1: CLIENT
Browser, mobile app, or API consumer. Sends HTTP requests. Renders HTML/CSS/JS responses.
Stores and retrieves application data. MySQL, PostgreSQL, MongoDB, Oracle.
Attack surface: SQL injection, NoSQL injection, access control
Most critical web vulnerabilities target Tier 2 — the application layer where user input meets server-side processing.
HTTP Request & Response Anatomy — Every Field Matters
Every web vulnerability involves HTTP — either manipulating a request, or exploiting how a server generates a response. You need to be able to read an HTTP message the way a developer reads source code — understanding what every line means and where it could be abused. Burp Suite (Day 12) makes this visual; today we understand the raw format it shows you.
The HTTP Request
Full HTTP POST request — annotated
POST/api/loginHTTP/1.1 ← method | endpoint | version
Host: target.com ← required; server needs this for virtual hosting
User-Agent: Mozilla/5.0 (Kali Linux) ← browser ID — easy to spoof
Content-Type: application/json ← tells server how to parse the body
Content-Length: 42 ← byte length of body
Cookie: session=eyJhbGc… ← authentication token — most valuable header
Authorization: Bearer eyJhbGc… ← API authentication
Referer: https://target.com/login ← where this request came from
← blank line separates headers from body
{“username”:”admin”,”password”:”test”} ← request body
# Server header present → version fingerprinting for attackers
# Cookie HttpOnly flag → JS cannot access → XSS can’t steal it
# Cookie Secure flag → only sent over HTTPS
💡 Security headers are a quick win: Checking which security headers are present (or absent) takes 30 seconds with curl -I https://target.com. Missing security headers are often low-to-medium findings in penetration test reports that are easy to implement and meaningfully reduce attack surface. In bug bounty, they rarely pay — but they demonstrate thoroughness.
HTTP Methods & Status Codes — Reading the Conversation
3xx Redirect — 301 Moved, 302 Found, 307 Temp. Watch for open redirects.
4xx Client Error — 400 Bad Request, 401 Unauthorised, 403 Forbidden, 404 Not Found. 403 ≠ 404 — resource exists but access denied.
5xx Server Error — 500 Internal Error, 502 Bad Gateway, 503 Service Unavailable. Server errors often reveal stack traces — valuable intel.
# Check allowed methods on a target
curl -X OPTIONS https://target.com/api/ -I
Allow: GET, POST, PUT, DELETE
# DELETE enabled = potential data destruction without auth
Cookies, Sessions & State Management — The Authentication Backbone
HTTP is stateless — each request is independent and the server has no memory of previous interactions. Sessions and cookies are the mechanism that adds state to a stateless protocol, allowing you to stay “logged in” across multiple requests. Understanding this mechanism is the foundation for understanding authentication attacks, session hijacking, and CSRF.
The cookie lifecycle — from login to session management
# Step 1: User logs in — server validates credentials
# Attacker uses it to log in as victim — no password needed
# HttpOnly flag prevents: document.cookie is undefined
JWT Tokens — The Modern Alternative to Session Cookies
Modern APIs increasingly use JSON Web Tokens (JWT) instead of traditional session cookies. A JWT is a self-contained token that encodes the user’s identity and permissions, cryptographically signed by the server. Understanding JWT structure is essential for web application testing because JWT vulnerabilities are consistently found in bug bounty programmes.
JWT anatomy — a token that tells the server who you are
# A JWT looks like this (three base64-encoded parts separated by dots):
# Change “role”:”user” → “role”:”admin” in payload
# Remove the signature — if server accepts “none” algorithm…
# You just escalated yourself to admin with no credentials
Authentication Mechanisms — What’s Protecting the Door
Authentication is the process of verifying identity. Web applications implement it in several ways, each with distinct security properties and failure modes. As a security tester, you need to understand what mechanism is in use before you can test it effectively.
🔑
Form-Based Authentication
Username + password submitted via HTML form (POST). Server validates against stored hash, creates session, sets cookie. Most common mechanism. Vulnerable to: brute force, credential stuffing, CSRF on logout, session fixation, and predictable session IDs.
🔐
HTTP Basic Authentication
Username:password base64-encoded in the Authorization header on every request. Not encrypted by itself — requires HTTPS. No session — credentials sent every time. Found on internal APIs and legacy systems. Often uses default credentials. Hydra supports it directly.
🎫
Token-Based (JWT / OAuth 2.0)
Self-contained token issued after authentication. Sent in Authorization: Bearer header. Common in REST APIs and single-page applications. Vulnerabilities include: algorithm confusion (“none”), weak secrets (brute-forceable HMAC keys), missing expiration, sensitive data in unencrypted payload, and confused deputy attacks in OAuth flows.
🔏
API Key Authentication
Static secret key passed in header (X-API-Key) or query parameter. Simple but has significant weaknesses: keys often embedded in client-side code, leaked to version control, logged in URLs, and rarely rotated. Finding API keys in JavaScript source, GitHub repos, or URL logs is one of the most common bug bounty findings.
Same-Origin Policy & CORS — The Browser’s Security Boundary
The Same-Origin Policy (SOP) is one of the most fundamental browser security mechanisms. It prevents JavaScript on one origin from reading data returned from a different origin. Without it, any website you visit could read your emails, bank statements, or any other authenticated content in another tab.
Same-Origin Policy — what counts as “same origin”
# Same origin requires: identical scheme + hostname + port
https://target.com:443/page ← ORIGIN
https://target.com:443/other ✓ Same origin (path differs, irrelevant)
http://target.com:443/page ✗ Different scheme (http vs https)
https://sub.target.com/page ✗ Different hostname
https://target.com:8443/page ✗ Different port
# CORS — Cross-Origin Resource Sharing — intentionally relaxes SOP
# Server can say: “I trust requests from https://app.target.com”
# If response includes: Access-Control-Allow-Origin: https://evil.com
# The server trusts any origin — potentially exploitable
OWASP Top 10 — Your Web Application Attack Map
The OWASP Top 10 is the most referenced web security standard in the world. Every penetration test report, every compliance framework, and every security training programme references it. Over the next 24 days we’ll cover each category in depth. Today — understand what each one means at a conceptual level and where it fits into what you already know.
#
Category
What It Means
Course Day
A01
Broken Access Control
Users accessing resources/actions beyond their permissions (IDOR, privilege escalation)
Day 16
A02
Cryptographic Failures
Sensitive data exposed — weak encryption, HTTP instead of HTTPS, plaintext storage
Day 10
A03
Injection
Untrusted data sent to interpreter — SQL, NoSQL, OS command, LDAP injection
Days 13, 14 & 19
A04
Insecure Design
Fundamental design flaws — missing threat modelling, business logic errors
2025 update: the table above is the 2021 edition. OWASP published the Top 10:2025 in November 2025. It moves Security Misconfiguration up to A02, adds Software Supply Chain Failures (A03) and Mishandling of Exceptional Conditions (A10), and folds SSRF into Broken Access Control. The vulnerabilities you practise in this course are the same either way.
💡 Notice A01 — Broken Access Control: It’s the #1 category, not Injection. The shift reflects a decade of industry learning: access control is harder to test automatically, easier to miss in code review, and devastatingly common. We spend two full days on it (Days 16–17) because it appears in nearly every real assessment.
Mapping a Web Application’s Attack Surface — Before You Test Anything
Before touching Burp Suite or firing any payloads, a professional spends time mapping the application — understanding every entry point, every function, every piece of technology. This reconnaissance phase shapes everything that comes after. Here’s the systematic approach I use on every web application engagement.
Web application attack surface mapping — systematic approach
# 1. Technology fingerprinting — what’s running?
curl -I https://target.com # Check response headers for Server, X-Powered-By
Setting Up DVWA — Your Web Application Practice Target
DVWA (Damn Vulnerable Web Application) is a deliberately vulnerable PHP/MySQL web application built specifically for security training. Every OWASP vulnerability category we cover over the next 24 days has a dedicated exercise in DVWA. Install it in your Kali lab now — it’ll be your practice ground for the rest of Phase 2.
Installing DVWA on Kali Linux
# Option 1: Install via apt (easiest on modern Kali)
sudo apt update && sudo apt install dvwa -y
sudo dvwa-start
# Opens at: http://127.0.0.1:42001/dvwa
# Option 2: Manual install on Metasploitable 2
# DVWA is already installed — just browse to:
http://192.168.56.101/dvwa
Default credentials: admin / password
# After login — setup the database
# Click “Create / Reset Database” on the setup page
# Set security level to “Low” for initial practice
Which security headers are present? Which are missing? Note the Server header — does it reveal software versions?
2
Set up DVWA and confirm all modules load correctly
Install DVWA (apt or Metasploitable). Login with admin/password. Set Security Level to Low. Click through all 13 vulnerability modules and confirm they load. This is your lab for Days 12–35.
3
Decode a JWT from DVWA’s session cookie
# After logging into DVWA, open browser DevTools → Application → Cookies # Copy the PHPSESSID value, then paste any JWT-looking token at: https://jwt.io # Decode and inspect the payload
What information is stored in the token? Is it a traditional session ID or a JWT?
★
Map DVWA’s complete attack surface manually
Browse every page in DVWA. List every: form input field, URL parameter, cookie, and HTTP method used. This is your attack surface map. Save it to ~/Day11/dvwa_attack_surface.txt. Day 12 we load this into Burp Suite and start intercepting these requests.
⭐ BONUS CHALLENGE — CORS Testing
Test DVWA’s CORS configuration — does it accept requests from arbitrary origins?
curl -H “Origin: https://evil.com” -I http://192.168.56.101/dvwa/ # Look for Access-Control-Allow-Origin in the response # Is evil.com reflected? That’s a CORS misconfiguration.
Note your findings 🌐
🌐
The web is no longer a black box. You see every layer — and where each one breaks.
Day 12 is where Phase 2 gets hands-on: Burp Suite setup, intercepting your first real web request, and beginning to manipulate live traffic. Everything we covered today — HTTP, cookies, sessions — you’ll see it flowing through Burp in real time. It’s one of the most satisfying sessions in the whole course.
Frequently Asked Questions — Day 11 Web Application Security Basics
Why is Broken Access Control the #1 OWASP risk?
Access control is the #1 risk because it’s pervasive, hard to detect automatically, and often missed in code review. Unlike SQL injection (which scanners detect), access control issues require understanding the application’s intended behaviour — knowing that user ID 1337 shouldn’t be able to read user ID 9999’s data requires understanding context. This is why human security testing finds far more access control issues than automated scanning.
What is the difference between authentication and authorisation?
Authentication answers “who are you?” — it’s the process of verifying identity (login). Authorisation answers “what are you allowed to do?” — it’s the process of determining what an authenticated user can access or perform. Many applications implement authentication correctly but authorisation poorly — allowing authenticated users to access other users’ data (IDOR) or perform admin actions (privilege escalation). Both are tested in a security assessment, and both appear in the OWASP Top 10.
What tools are used for web application penetration testing?
Core tools: Burp Suite (HTTP proxy, Repeater, Intruder — the automated scanner is Pro-only — covered Day 12), FFUF or Gobuster (directory/endpoint discovery), SQLMap (automated SQLi), Nikto (web server scanner), WhatWeb (technology fingerprinting), and browser DevTools. All are pre-installed on Kali or installed via apt. We cover each tool in depth on the day we use it for a specific vulnerability category.
Is DVWA safe to run on my main computer?
DVWA running inside a VirtualBox VM on a host-only network is safe — it’s isolated from your real network and the internet. Running DVWA directly on your host machine and exposing it to a network is extremely unsafe and should never be done. The deliberate vulnerabilities in DVWA are real, exploitable flaws. Always run it inside a properly isolated VM as we set up on Day 2.
Web application security is where I’ve spent the majority of my professional career. The reason is simple: every organisation has a web application, most have significant vulnerabilities in them, and the impact of those vulnerabilities — data breaches, account takeovers, business logic abuse — is immediate and measurable. Eleven days in and you’re now ready to go deep into the most impactful area of this field.
Founder of Securityelites and creator of the SE-ARTCP credential. Working penetration tester focused on AI red team, prompt injection research, and LLM security education.
