Web Application Security
Web application testing rewards a methodical mapping of the attack surface before exploitation. Know the OWASP-style failure families: broken access control (IDOR, missing function-level checks, path traversal), injection (SQLi, command injection, template injection, XSS as a client-side injection), authentication and session weaknesses (weak credential policy, predictable tokens, missing rotation on privilege change), and misconfiguration (verbose errors, default accounts, exposed admin interfaces, permissive CORS). Understand the difference between reflected, stored, and DOM-based XSS, and why output encoding must be context-specific (HTML body, attribute, JavaScript, URL) while CSP is defense-in-depth rather than a fix.
Traps to expect: confusing authentication with authorization; assuming HTTPS means secure; treating a CSRF token as protection against XSS; and misreading SameSite cookie behavior. Also watch for questions that conflate server-side request forgery with open redirect, or that present a filter bypass as proof of exploitability when the sink is actually safe.
Worked example: an endpoint /api/invoice?id=1001 returns another user's invoice when the ID is changed. The finding is broken access control (horizontal privilege escalation), not SQL injection, because the parameter is used directly as an object reference. The remediation is a server-side ownership check tied to the authenticated principal, not input validation alone. Rule of thumb: for any user-supplied identifier, ask who is allowed to access the referenced object and whether the server verifies that relationship on every request.