Web Application Architecture | Web Application Security

Welcome to the Architectural Crime Scene

Imagine you're a burglar (ethically, of course) trying to break into a building. You wouldn't just start kicking random walls - you'd study the blueprints, find the ventilation shafts, locate the security room, and map out escape routes. Web application architecture is your blueprint.

Understanding how web applications are built isn't just nice to have - it's essential. Every vulnerability exists because of an architectural decision. SQL injection? That's the database layer. XSS? That's the frontend. SSRF? That's the server making requests. Know the architecture, know where to attack.

This lesson connects everything you've learned in

How HTTP Works

and

Cookies and Sessions

into a cohesive picture of how modern web apps function - and fail.

The Three-Tier Architecture

Most web applications follow a three-tier (or three-layer) architecture. Think of it like a restaurant:

Presentation Tier (Frontend) - The dining room where customers interact. This is what users see: HTML, CSS, JavaScript, React, Angular, etc.
Application Tier (Backend) - The kitchen where orders are processed. This is where business logic lives: Python/Django, Node.js, PHP, Java, etc.
Data Tier (Database) - The pantry/storage room. Where all the ingredients (data) are kept: MySQL, PostgreSQL, MongoDB, etc.

1┌──────────────────────────────────────────────────────────────────┐
2│                        USER'S BROWSER                             │
3│  (Frontend: HTML, CSS, JavaScript, React/Vue/Angular)             │
4└────────────────────────────────┬─────────────────────────────────┘
5                                 │ HTTP/HTTPS
6                                 ▼
7┌──────────────────────────────────────────────────────────────────┐
8│                    REVERSE PROXY / LOAD BALANCER                  │
9│  (Nginx, Cloudflare, AWS ALB)                                    │
10└────────────────────────────────┬─────────────────────────────────┘
11                                 │
12                                 ▼
13┌──────────────────────────────────────────────────────────────────┐
14│                      WEB SERVER / APPLICATION                     │
15│  (Node.js, Python/Flask/Django, PHP, Java/Spring, Go)            │
16│  Business Logic, Authentication, Session Management              │
17└────────────┬─────────────────────────────┬───────────────────────┘
18             │                             │
19             ▼                             ▼
20┌─────────────────────────┐   ┌─────────────────────────┐
21│      DATABASE           │   │    EXTERNAL SERVICES    │
22│  (MySQL, PostgreSQL,    │   │  (APIs, Cloud Storage,  │
23│   MongoDB, Redis)       │   │   Payment Gateways)     │
24└─────────────────────────┘   └─────────────────────────┘

As a security tester, you're looking for places where data crosses boundaries. Every arrow in that diagram is a potential attack vector.

The Presentation Tier: Where XSS Lives

The frontend is everything that runs in the user's browser. It's responsible for displaying information and capturing user input. From a security perspective, it's both a target and a weapon.

Traditional vs Modern Frontends

1TRADITIONAL (Server-Side Rendering)
2─────────────────────────────────
3Browser → Server → Generates HTML → Browser displays
4 
5Example: PHP, Ruby on Rails, Django templates
6- Server generates complete HTML pages
7- Each page load = new HTTP request
8- XSS happens when user input is reflected in HTML
9 
10MODERN (Single Page Applications)
11───────────────────────────────────
12Browser → API → JSON → JavaScript renders
13 
14Example: React, Vue, Angular
15- Server sends JavaScript bundle once
16- JavaScript fetches data via APIs
17- DOM updates without full page reloads
18- New attack vectors: DOM XSS, prototype pollution

Frontend Security Concerns

XSS (Cross-Site Scripting) - Injecting malicious scripts that execute in users' browsers. See
Related
XSS Fundamentals
DOM Manipulation - Attackers can modify what users see or steal data through JavaScript
Sensitive Data Exposure - API keys, credentials, or internal URLs hardcoded in JavaScript
Client-Side Validation Bypass - Any validation in JavaScript can be bypassed by sending requests directly to the API

NEVER trust client-side validation. That fancy JavaScript form validator? An attacker will bypass it with one curl command. Server-side validation is mandatory.

Finding Secrets in JavaScript

Modern web apps ship massive JavaScript bundles. These often contain secrets developers forgot to remove:

javascript

1606070;">// Things to search for in JavaScript files:
2API_KEY
3SECRET
4PASSWORD
5TOKEN
6AWS_ACCESS
7PRIVATE_KEY
8Authorization
9Bearer
10Basic
11.env
12config
13localhost
14internal
15admin
16 
17606070;">// Tools to help:
18606070;">// - Browser DevTools Sources tab
19606070;">// - LinkFinder (finds endpoints in JS)
20606070;">// - SecretFinder (finds secrets in JS)

The Application Tier: Where the Magic (and Mayhem) Happens

The backend is the brain of the operation. It handles authentication, processes business logic, talks to databases, and integrates with external services. It's also where most critical vulnerabilities live.

Common Backend Technologies

1LANGUAGE        FRAMEWORKS              COMMON VULNS
2──────────────────────────────────────────────────────────────
3Python          Django, Flask, FastAPI  SQLi, SSTI, Command Injection
4JavaScript      Express, Next.js, Nest  Prototype Pollution, NoSQL injection
5PHP             Laravel, Symfony        SQLi, File inclusion, Deserialization
6Java            Spring Boot             Deserialization, XXE, SSTI
7Ruby            Rails, Sinatra          Mass assignment, SSTI
8Go              Gin, Echo               Less common, but still SQLi, SSRF
9 
10Identifying the stack helps you know which vulnerabilities to test for!

Authentication & Session Management

The backend decides who you are (authentication) and what you can do (authorization). Common patterns include:

1SESSION-BASED AUTHENTICATION
2─────────────────────────────
31. User logs in with username/password
42. Server creates session, stores in database/Redis
53. Server sends session ID in cookie
64. Browser sends cookie with every request
75. Server validates session ID
8 
9Attacks: Session hijacking, session fixation, CSRF
10 
11TOKEN-BASED AUTHENTICATION (JWT)
12────────────────────────────────
131. User logs in with username/password
142. Server creates signed JWT token
153. Token sent to client (cookie or localStorage)
164. Client sends token in Authorization header
175. Server validates signature
18 
19Attacks: Algorithm confusion, weak secrets, token theft
20 
21OAUTH 2.0 / SOCIAL LOGIN
22─────────────────────────
231. User clicks 606070;">#a5d6ff;">"Login with Google"
242. Redirect to Google's auth server
253. User authenticates with Google
264. Redirect back with authorization code
275. Server exchanges code for access token
28 
29Attacks: Open redirect, CSRF, token leakage

When testing authentication, always check: Can you log in as another user? Can you escalate privileges? Can you bypass MFA? See

Authentication Attacks

for exploitation techniques.

Backend Attack Surfaces

SQL Injection - When user input reaches database queries unsanitized
Command Injection - When user input reaches shell commands
SSRF - When the server can be tricked into making requests to internal resources
XXE - When XML input is parsed with external entity processing enabled
Deserialization - When untrusted data is deserialized
SSTI - When user input reaches template engines

APIs: The New Attack Surface

Modern applications are API-driven. Instead of servers generating HTML, they expose APIs that frontends consume. This creates new opportunities for attackers.

REST APIs

RESTful APIs use standard HTTP methods to perform CRUD operations:

1METHOD   PATH                    ACTION
2───────────────────────────────────────────────────────
3GET      /api/users              List all users
4GET      /api/users/123          Get user 123
5POST     /api/users              Create new user
6PUT      /api/users/123          Update user 123
7PATCH    /api/users/123          Partial update
8DELETE   /api/users/123          Delete user 123
9 
10Security Testing Checklist:
11□ Can you access /api/users without authentication?
12□ Can you access /api/users/456 (another user's data)?
13□ Can you POST/PUT/DELETE without proper authorization?
14□ What happens with invalid IDs? (SQL errors?)
15□ Are there undocumented endpoints? (/api/admin, /api/internal)

GraphQL APIs

GraphQL is a query language for APIs that lets clients request exactly what they need. It's powerful... and often misconfigured:

javascript

1606070;"># GraphQL Introspection Query (often left enabled!)
2{
3  __schema {
4    types {
5      name
6      fields {
7        name
8        type {
9          name
10        }
11      }
12    }
13  }
14}
15 
16606070;"># This reveals the ENTIRE API schema!
17606070;"># Endpoints, parameters, types - everything
18 
19606070;"># Dangerous mutations to test:
20mutation {
21  updateUser(id: 606070;">#a5d6ff;">"456", role: "admin") {
22    id
23    role
24  }
25}
26 
27606070;"># Batch queries (can bypass rate limiting):
28{
29  user1: user(id: 606070;">#a5d6ff;">"1") { password }
30  user2: user(id: 606070;">#a5d6ff;">"2") { password }
31  user3: user(id: 606070;">#a5d6ff;">"3") { password }
32  606070;"># ... 1000 more
33}

GraphQL introspection is like leaving the database schema on a public billboard. Always test for it with: /graphql?query={__schema{types{name}}}

API Documentation Discovery

Common API documentation endpoints to check:

1606070;"># Swagger / OpenAPI
2/swagger
3/swagger.json
4/swagger/v1/swagger.json
5/api-docs
6/api/swagger
7/swagger-ui.html
8 
9606070;"># GraphQL
10/graphql
11/graphiql
12/playground
13/altair
14 
15606070;"># Generic
16/api
17/api/v1
18/api/v2
19/docs
20/redoc
21 
22Finding API docs = Finding the attack surface map

The Data Tier: Where Your Prizes Live

The database holds everything valuable: user credentials, personal information, financial data, business secrets. It's the ultimate target, and it's protected by the application layer... hopefully.

Database Types and Their Vulnerabilities

1RELATIONAL DATABASES (SQL)
2──────────────────────────
3MySQL, PostgreSQL, Oracle, SQL Server, SQLite
4 
5Vulnerabilities:
6- SQL Injection (classic and blind)
7- Privilege escalation (INTO OUTFILE, xp_cmdshell)
8- Information disclosure (error messages)
9 
10NoSQL DATABASES
11───────────────
12MongoDB, CouchDB, Redis, Cassandra
13 
14Vulnerabilities:
15- NoSQL Injection (operator injection)
16- Default credentials (MongoDB had no auth by default!)
17- Exposed management interfaces
18 
19EXAMPLE NoSQL INJECTION:
20606070;">// Intended query:
21db.users.find({user: 606070;">#a5d6ff;">"admin", pass: "password123"})
22 
23606070;">// Injected query:
24db.users.find({user: 606070;">#a5d6ff;">"admin", pass: {$ne: ""}})
25606070;">// $ne means "not equal" - matches ANY non-empty password!

SQL databases use structured queries with strict syntax. NoSQL databases often accept JSON/JavaScript objects, enabling different injection techniques. See

SQL Injection Fundamentals

for detailed exploitation.

Infrastructure Components

Beyond the three tiers, modern applications have supporting infrastructure that can be exploited:

Reverse Proxies & Load Balancers

1COMMON REVERSE PROXIES
2──────────────────────
3Nginx, Apache, HAProxy, Cloudflare, AWS ALB
4 
5Purpose:
6- Distribute traffic across multiple servers
7- SSL/TLS termination
8- Caching static content
9- WAF (Web Application Firewall)
10 
11Attack Vectors:
12- HTTP Request Smuggling (proxy vs backend disagree)
13- Cache Poisoning (manipulate cached responses)
14- Host Header Injection
15- IP Spoofing via X-Forwarded-For

Caching Layers

1CACHE TYPES
2───────────
3CDN (Cloudflare, Akamai, CloudFront)
4Application Cache (Redis, Memcached)
5Browser Cache
6 
7Web Cache Poisoning Example:
8─────────────────────────────
91. Attacker sends:
10   GET /page HTTP/1.1
11   Host: victim.com
12   X-Forwarded-Host: evil.com
13 
142. Server generates response with evil.com links
153. Response gets cached
164. All subsequent users get poisoned page!
17 
18This works when cache key doesn't include X-Forwarded-Host
19but the application uses it to generate content.

Cloud Services

1COMMON CLOUD MISCONFIGURATIONS
2──────────────────────────────
3AWS S3 Buckets:
4- Public read/write access
5- Listing enabled
6- Check: https:606070;">//BUCKET.s3.amazonaws.com
7 
8AWS Metadata Service:
9- Accessible at http:606070;">//169.254.169.254
10- SSRF target for credential theft
11 
12Firebase:
13- Open database rules
14- Check: https:606070;">//PROJECT.firebaseio.com/.json
15 
16Azure Blob Storage:
17- Public containers
18- Check: https:606070;">//ACCOUNT.blob.core.windows.net/CONTAINER?restype=container&comp=list

Mapping the Attack Surface

Before you start testing, map out what you're dealing with. Here's a systematic approach:

Attack Surface Discovery

Identify the Tech Stack

Check HTTP headers (Server, X-Powered-By)
Look at cookies (PHPSESSID = PHP, JSESSIONID = Java)
View page source for framework signatures
Use Wappalyzer browser extension

Discover Endpoints

Spider the application with Burp Suite
Check robots.txt, sitemap.xml
Directory brute force (gobuster, dirsearch)
Analyze JavaScript for API endpoints
Look for API documentation (swagger, graphql)

Identify Input Points

URL parameters (?id=123)
POST body data
HTTP headers (Host, Cookie, User-Agent, Referer)
File uploads
WebSocket messages

Map Data Flow

Where does user input go?
What processing happens?
Where is data stored?
Where is data reflected back?

Identify Trust Boundaries

Authenticated vs unauthenticated areas
Admin vs user functionality
Internal vs external services
Same-origin vs cross-origin

Practice Challenges

Stack Detective

Challenge

🔥 medium

You're testing a web application. From the HTTP response headers and page behavior, determine the technology stack. Response Headers: - Server: nginx/1.18.0 - X-Powered-By: Express - Set-Cookie: connect.sid=abc123; HttpOnly The login page submits to /api/auth/login and returns JSON. Failed logins return: {"error": "Invalid credentials", "code": "AUTH_FAILED"} What technologies are likely being used?

Need a hint? (4 available)

API Discovery

Challenge

🔥 medium

You've found a web application at https://target.com. The main page loads a JavaScript-heavy SPA. Your task is to find all API endpoints. Using browser DevTools, you find main.bundle.js contains: - fetch("/api/v2/users/" + userId) - axios.post("/api/v2/orders", orderData) - baseURL: "https://api.target.com" What API endpoints should you test, and what security checks would you perform?

Need a hint? (4 available)

Knowledge Check

Web Architecture Quiz

Question 1 of 5

In a three-tier architecture, where does business logic typically execute?

Key Takeaways

Three-tier architecture (presentation, application, data) defines where different vulnerabilities occur
Frontend security focuses on XSS and client-side data exposure; never trust client-side validation
Backend security is where most critical vulns live: SQLi, command injection, SSRF, SSTI, deserialization
APIs are the new attack surface - check for authentication, authorization, and exposed documentation
Technology identification guides your testing - HTTP headers, cookies, and error messages reveal the stack
Map the attack surface before testing: endpoints, input points, data flow, and trust boundaries

Related Lessons

How HTTP Works

Deep dive into the protocol that powers web communication

SQL Injection Fundamentals

Exploit the data tier through injection attacks

XSS Fundamentals

Attack the presentation tier with client-side scripts

IDOR Vulnerabilities

Exploit broken access control in APIs