Web Application Security

Deep dives (learn each topic properly)

Web security is about two things: (1) permissions (who can do what) and (2) input safety (user input should not control the server or the browser).

What I see in reviews: these issues usually slip through because everything looks “fine” in happy-path testing — until one weird request hits production.

60-second interview answer: “I start by mapping roles and key objects, then I test authorization first (IDOR/BOLA/BFLA). Next I test input-handling risks (SQLi, XSS, SSRF, file upload). Then I validate state and workflow issues (CSRF, session issues, business logic, race conditions). Finally I provide actionable fixes and retest.”

Deep dive methodology

1) Build the model (how experienced testers start)

Roles: anonymous, user, admin, support, partner, internal service accounts
Objects: user profile, orders, invoices, tickets, wallets, documents
Workflows: draft → submit → approve → pay → ship (logic bugs hide here)
Trust boundaries: browser ↔ API ↔ services ↔ DB/cache ↔ third parties

2) Repeatable workflow

Recon: enumerate endpoints, params, content-types, auth requirements
Baseline: capture “golden requests” for key actions
AuthZ matrix: replay baseline requests across roles/users and compare behavior
Input-handling: injection families, SSRF, template issues, uploads
State/workflow: CSRF, sessions, idempotency, races, logic abuse
Report + fix guidance: specific changes + tests; then retest

High-yield vulnerabilities

Vulnerability	Explain simply	How to test (interview-safe)	How to fix
IDOR / Broken Object Level Auth (BOLA)	Change an ID and you see/modify someone else’s data.	Swap object IDs across accounts/roles. Check nested IDs (e.g., orderId + itemId). Compare responses and side effects.	Server-side ownership checks on every request. Deny-by-default. Centralized policy enforcement (RBAC/ABAC).
Broken Function Level Auth (BFLA)	Normal user can call admin-only functions.	Call privileged routes/methods with low-priv tokens. Test method changes (GET/POST/PUT) and hidden endpoints.	Enforce role checks centrally; separate admin surfaces; add tests for role coverage.
SQL Injection	Input changes the database query.	Look for error/time/boolean differences. Confirm with minimal safe proof and clear impact (read/write).	Parameterized queries/ORM. Least privilege DB roles. Validation. Monitoring.
XSS	Attacker runs script in users’ browsers.	Find reflection/storage sinks. Confirm context (HTML/attr/JS/URL). Validate CSP and encoding.	Contextual output encoding. Sanitization where needed. Avoid dangerous DOM sinks. Strong CSP.
CSRF	Victim’s browser performs actions automatically.	Check state-changing endpoints using cookies. Validate CSRF tokens + SameSite behavior.	CSRF tokens + SameSite cookies. Re-auth for sensitive actions.
SSRF	Server makes requests to internal/forbidden places.	Test any URL fetcher (preview, webhook, import). Validate allow-lists and internal range blocks. Consider redirects.	Allow-list destinations, block RFC1918/link-local, disable redirects, egress controls, timeouts.
File upload	Upload becomes code execution or data exposure.	Check content validation, storage location, permissions, and direct-access URLs. Look for parser issues.	Store outside webroot, random filenames, strict content validation, scanning, no execute perms.

This page is intentionally focused on interview-safe testing and remediation guidance, not step-by-step exploitation.

Advanced topics interviewers love

Business logic flaws

Plain: The “rules of the app” can be abused (price, coupon, workflow).

Deep: Identify invariants (price must be server-calculated, state transitions must be valid). Test multi-step flows (checkout, refunds, transfers, KYC) for bypasses and edge cases.

Fix: Server-side validation of invariants, transactional updates, audit logs, and regression tests.

Race conditions & idempotency

Plain: Doing the same action quickly many times breaks logic.

Deep: Look for “double spend” patterns: apply coupon, purchase, withdraw, redeem. Concurrency issues happen when the server assumes 1 request at a time.

Fix: Idempotency keys, unique constraints, atomic DB transactions, locking where needed.

Deserialization & mass assignment

Plain: The server trusts hidden fields or converts untrusted data into objects unsafely.

Deep: Mass assignment: extra JSON fields update restricted attributes (role, status, price). Unsafe deserialization: untrusted data becomes runtime objects with dangerous side effects.

Fix: Allow-list DTOs, schema validation, disable unsafe polymorphic parsing, strict mappers.

SSRF → cloud impact (interview framing)

Plain: SSRF can sometimes reach internal identity endpoints and leak credentials.

Deep: Explain the chain: SSRF → internal endpoint access → credentials → privilege escalation → data access. Then list mitigations: allow-lists, block internal ranges, cloud metadata hardening, egress controls.

Burp Suite workflow that sounds experienced

Create “golden requests” for key actions and keep them clean and labeled.
Use response diffing across roles to prove authorization boundaries.
Keep evidence organized as you go (request/response + business impact statement).
Prefer minimal PoCs that prove impact without being destructive.

Safety note: for interview prep and