🌐 Module 6 · Application TM
Web Applications & APIs
Real-world web apps are multi-tier, API-driven, and OAuth-enabled. This module covers the threat landscape for modern web architecture — REST APIs, OAuth 2.0 flows, frontend injection, and microservices.
🎯 Learning Objectives
- Threat model a multi-tier web application with a separate API layer
- Identify threats specific to OAuth 2.0 and token-based auth flows
- Map OWASP Top 10 to STRIDE categories
- Enumerate API-specific threats: broken object-level auth, mass assignment, rate limiting
- Understand cross-site attacks: XSS, CSRF, CORS misconfigurations
1Multi-Tier Web Architecture
Modern web apps separate concerns into distinct tiers. Each tier boundary is a new trust boundary — and a new attack surface.
Presentation Tier — Browser / Mobile Client
React/Vue/Angular SPA or native mobile app. Runs entirely in the user's environment. Treat all client-side logic as untrusted. Attackers can modify JS, intercept requests, and replay tokens. Never enforce security controls client-side only.
Edge Tier — CDN, Load Balancer, API Gateway
First line of defense. TLS termination, DDoS mitigation, WAF rules, rate limiting, bot detection. Threats: gateway bypass, misconfigured CORS, TLS downgrade attacks.
Application Tier — API Servers, Microservices
Business logic lives here. Authentication/authorization enforcement, input validation, business rule processing. Threats: injection, broken auth, SSRF, XXE, deserialization flaws.
Data Tier — Databases, Caches, Queues
Persistent state. SQL/NoSQL databases, Redis caches, message queues. Threats: SQL injection (if app tier fails), over-privileged DB users, unencrypted sensitive fields, cache poisoning.
Infrastructure Tier — OS, Containers, Network
Hosting environment. Threats: container escapes, privilege escalation via OS exploits, lateral movement via open internal network ports, secrets leakage via environment variables.
2OWASP Top 10 Mapped to STRIDE
The OWASP Top 10 is the industry's most-referenced list of critical web application risks. Here's how it maps to STRIDE — connecting what OWASP names to what STRIDE categorizes:
| OWASP Top 10 (2021) | STRIDE | Core Risk | Example |
|---|---|---|---|
| A01: Broken Access Control | E · I | IDOR, privilege escalation, path traversal | User accesses admin panel without admin role |
| A02: Cryptographic Failures | I | Weak encryption, plaintext secrets, TLS downgrade | Passwords stored as MD5 hashes |
| A03: Injection | T · I · E | SQL, NoSQL, OS command, LDAP injection | SQL injection via unsanitized search field |
| A04: Insecure Design | S · T · E | Missing threat models, design-level flaws | Password reset doesn't verify email ownership |
| A05: Security Misconfiguration | I · D | Default creds, open S3 buckets, verbose errors | Debug mode on in production |
| A06: Vulnerable Components | T · I · E | Outdated libraries with known CVEs | Log4Shell in an old Log4j version |
| A07: Auth Failures | S · E | Weak passwords, session fixation, no MFA | Session token not invalidated after logout |
| A08: Software/Data Integrity | T | CI/CD pipeline attacks, insecure deserialization | Malicious npm package in build pipeline |
| A09: Logging Failures | R | No audit trail, sensitive data in logs | Failed logins not logged → breach goes undetected |
| A10: SSRF | I · E | Server makes requests to internal resources | Image URL parameter fetches AWS metadata endpoint |
3OAuth 2.0 Threat Model
OAuth 2.0 is everywhere — "Login with Google/GitHub/Facebook." But its flows introduce complex trust relationships and several well-known attack vectors. Let's model them.
OAuth 2.0 Authorization Code Flow — with Threat Points
OAuth 2.0 Authorization Code Flow — four critical threat points highlighted
| ID | OAuth Threat | STRIDE | Mitigation |
|---|---|---|---|
| T-01 | Missing 'state' parameter — CSRF allows attacker to trick user into linking their account with the attacker's identity | S | Always generate cryptographically random state; validate on callback |
| T-02 | Authorization code interception — code stolen from redirect URI, exchanged for tokens | S · T | Use PKCE (Proof Key for Code Exchange) — mandatory for public clients (SPAs, mobile) |
| T-03 | Client secret in SPA/mobile — decompilable, visible in source | I | Use PKCE instead of client_secret for public clients. Secrets are server-side only. |
| T-04 | Access token in URL fragment / query string — logged in browser history, server logs, Referer headers | I | Never pass tokens in URLs. Use Authorization Code flow (back-channel token exchange) not Implicit flow. |
| T-05 | Open redirect on redirect_uri — redirect_uri not strictly validated, tokens sent to attacker's server | S · I | Register exact redirect URIs, no wildcards. Validate against allowlist server-side. |
4Cross-Site Attacks: XSS & CSRF
Cross-Site Scripting (XSS)
STRIDE: Information Disclosure + Spoofing + Elevation of Privilege
XSS injects malicious JavaScript into a page viewed by other users. Three types:
Stored XSS
Malicious script saved to DB, served to all users who view the page. Highest impact — one payload, many victims.
Reflected XSS
Script in URL parameter, reflected back in response. Requires tricking user into clicking crafted link.
DOM-Based XSS
Script injected into DOM via client-side JS reading attacker-controlled data (URL, localStorage).
Mitigations
- Output encoding — encode all user data before rendering in HTML (
<not<) - Content Security Policy (CSP) — restrict which scripts can execute
- Use frameworks correctly — React's JSX auto-encodes; avoid
dangerouslySetInnerHTML - HttpOnly cookies — prevents JS from stealing session tokens even if XSS succeeds
Cross-Site Request Forgery (CSRF)
STRIDE: Spoofing + Tampering
CSRF tricks a logged-in user's browser into making unintended requests to a site where they're authenticated — without the user knowing.
How CSRF Works
User is logged into
The form auto-submits. The browser sends the user's session cookie automatically. The bank sees a valid authenticated request and processes the transfer.
bank.com. They visit evil.com, which has a hidden form:<form action="https://bank.com/transfer" method="POST">
<input name="amount" value="10000">
<input name="to" value="attacker-account">
</form>The form auto-submits. The browser sends the user's session cookie automatically. The bank sees a valid authenticated request and processes the transfer.
Mitigations
- CSRF tokens — random value in forms, validated server-side
- SameSite cookie attribute —
SameSite=StrictorLaxprevents cross-site cookie sending - Custom request headers — REST APIs check for
X-Requested-Withor custom header (browsers don't send these cross-origin without CORS preflight) - Double Submit Cookie — compare cookie value to request parameter
CORS Misconfiguration
STRIDE: Information Disclosure + Elevation of Privilege
CORS controls which origins can make cross-site API requests. A misconfigured CORS policy can undo all your other auth protections.
| Misconfiguration | Impact | Fix |
|---|---|---|
Access-Control-Allow-Origin: * with credentials |
Any site can read API responses with user's cookies | Never combine * with allow-credentials: true |
Reflecting Origin header without validation |
Any attacker origin is trusted | Validate against strict allowlist of origins |
null origin trusted |
Sandboxed iframes and file:// URIs can access API | Never trust Origin: null |
5API-Specific Threats (OWASP API Top 10)
APIs have their own unique threat landscape beyond the classic web app. The OWASP API Security Top 10 covers these. Here are the most critical:
API1: Broken Object Level Authorization (BOLA/IDOR)
APIs expose object identifiers directly. Without per-request ownership validation,
GET /api/invoices/4521 returns any invoice, not just the caller's. Most common and impactful API vulnerability.API3: Broken Object Property Level Authorization (Mass Assignment)
API blindly maps request body to model object. Client sends
{"name": "Alice", "isAdmin": true}. If the API doesn't filter which fields can be set by clients, the user promotes themselves to admin.// ❌ Mass assignment vulnerability
const user = await User.update(req.params.id, req.body); // All fields!
// ✅ Allowlist specific fields
const { name, email, bio } = req.body; // Only permitted fields
const user = await User.update(req.params.id, { name, email, bio });
API7: Server-Side Request Forgery (SSRF)
API fetches a URL supplied by the user (e.g., "import data from this URL" feature). Attacker supplies
http://169.254.169.254/latest/meta-data/ — the AWS metadata endpoint — to steal IAM credentials and compromise the entire cloud account.SSRF Mitigations
Validate and allowlist external URLs. Block requests to private IP ranges (10.x, 192.168.x, 172.16.x, 169.254.x). Disable unnecessary URL-fetching features. Use IMDSv2 on AWS (requires token header, defeats basic SSRF).
API4: Unrestricted Resource Consumption
No rate limits on expensive endpoints. Attacker hammers the PDF export endpoint with concurrent requests, exhausting server CPU. Or exfiltrates the entire user database by paginating through all records.
6Microservices Architecture Threats
When an app splits into microservices, the internal network becomes a new attack surface — one that often has far more trust than it should.
Microservices — Internal Trust Threats
Internal service-to-service communication is often implicitly trusted — a compromised service can attack all others
Key Microservices Threats
| Threat | STRIDE | Mitigation |
|---|---|---|
| Service impersonation — malicious service claims to be a trusted internal service | S | Mutual TLS (mTLS) for all service-to-service calls; service mesh (Istio/Linkerd) |
| Lateral movement — compromised service attacks all others on flat internal network | E | Network segmentation; principle of least privilege per service; service-level authorization |
| Secrets sprawl — each service hardcodes DB creds, API keys | I | Centralized secrets management (Vault, AWS Secrets Manager); service identities (not shared secrets) |
| Event queue poisoning — injecting malicious messages into Kafka/RabbitMQ | T | Message signing, input validation on consumer side; queue access controls |
7Knowledge Check
✏️ Exercise 6.1
OAuth 2.0 Code Interception
Your team is building a Single Page Application (SPA) that uses OAuth 2.0 for authentication. The SPA can't securely store a client_secret. What's the correct mitigation against authorization code interception?
✏️ Exercise 6.2
Spot the API Threat
A user profile API does:
User.update(id, req.body) without filtering fields. A user sends {"name": "Bob", "isAdmin": true, "creditBalance": 99999}. What vulnerability is this?8Module Summary
Key Takeaways
- Each architectural tier has its own threat profile — model them separately
- OWASP Top 10 maps directly to STRIDE — know both lists and their relationship
- OAuth 2.0: use Auth Code + PKCE for public clients; validate state; allowlist redirect URIs
- XSS: output encoding + CSP; CSRF: SameSite cookies + CSRF tokens
- API threats: BOLA/IDOR, mass assignment, SSRF — validate authorization on every request
- Microservices: don't trust internal network by default; use mTLS and least privilege per service