📰 Originally published on SecurityElites — the canonical, fully-updated version of this article.
DAY 11 OF 100
PHASE 2: WEB SECURITY
🟢 Day 11 — Web Application Security Basics
Day 100 — Professional Pentester
🌐 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.
📋 Day 11 Contents
- Client-Server Architecture
- HTTP Request & Response Anatomy
- HTTP Methods & Status Codes
- Cookies, Sessions & State Management
- Authentication Mechanisms
- Same-Origin Policy & CORS
- OWASP Top 10 — The Attack Map
- Mapping a Web App’s Attack Surface
- DVWA Setup & First Exploration
- Day 11 Practical Task
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.
Attack surface: DOM, client-side scripts, localStorage
⟷
⚙️
TIER 2: WEB SERVER / APP
Processes requests, applies business logic, queries database, returns responses.
Attack surface: input validation, auth, logic flaws
⟷
🗄️
TIER 3: DATABASE
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/login HTTP/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
Security-relevant observations:
1. Cookie header = session token → stealing this = account takeover
2. Content-Type determines parsing → changing it can bypass input filters
3. User-Agent is fully attacker-controlled → fingerprinting unreliable
4. JSON body → each field is a potential injection point
The HTTP Response
HTTP response — what the server sends back
HTTP/1.1 200 OK
← version | status code
Server: Apache/2.4.41 (Ubuntu)
← REVEALS SERVER TYPE & VERSION — info leak
Set-Cookie: session=abc123; Path=/; HttpOnly; Secure
← session cookie
X-Frame-Options: DENY
← prevents clickjacking attacks
Content-Security-Policy: default-src ‘self’
← prevents XSS
Strict-Transport-Security: max-age=31536000
← forces HTTPS
Content-Type: text/html; charset=UTF-8
← blank line
Security header analysis — missing headers = vulnerabilities:
Missing X-Frame-Options → clickjacking possible
Missing CSP → XSS more exploitable
Missing HSTS → SSL stripping possible
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
📖 Read the complete guide on SecurityElites
This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on SecurityElites →
This article was originally written and published by the SecurityElites team. For more cybersecurity tutorials, ethical hacking guides, and CTF walk-throughs, visit SecurityElites.
Top comments (0)