Web Security & WAF Interview Questions

Summary

The OWASP Top 10 is a consensus list of the most critical web application security risks. The 2025 edition lists: Broken Access Control, Security Misconfiguration, Software Supply Chain Failures, Cryptographic Failures, Injection, Insecure Design, Authentication Failures, Software or Data Integrity Failures, Security Logging and Alerting Failures, and Mishandling of Exceptional Conditions.

Longer Answer

Broken access control remains #1 (SSRF is now folded into it), supply-chain risk got its own category, and error handling that fails open is newly called out. The 2021 edition is still widely referenced (it listed Vulnerable and Outdated Components and SSRF separately). OWASP also publishes an API Security Top 10 (BOLA, broken authentication, broken object property level authorization, unrestricted resource consumption, …) and a Top 10 for LLM applications (prompt injection, sensitive information disclosure, excessive agency, …). Use them as awareness checklists, not a complete security program.

Key Points

• Broken access control is #1
• Supply chain failures now a category
• Injection includes XSS
• API and LLM Top 10 lists exist
• Awareness, not a full program

Summary

XSS lets attackers inject script into pages viewed by other users, stealing sessions or acting as them. Prevent it with context-aware output encoding (auto-escaping templates), sanitizing any HTML you must render (DOMPurify, nh3), avoiding dangerous sinks (innerHTML, dangerouslySetInnerHTML, eval), and a strict Content-Security-Policy.

Longer Answer

Types: stored (saved in DB), reflected (from the request), and DOM-based (client-side JS writes untrusted data into the DOM). Frameworks like React and Jinja escape by default, so XSS usually appears where developers bypass escaping or inject into URLs (javascript:), attributes, or script/style contexts. HttpOnly cookies limit session theft but don't stop XSS actions.

Key Points

• Stored, reflected, DOM-based
• Escape output per context
• Sanitize rich HTML
• Avoid dangerous sinks
• CSP as defense in depth

Summary

SQL injection occurs when untrusted input is concatenated into SQL, letting attackers change the query to read or modify data. Prevent it with parameterized queries/prepared statements (or ORMs used correctly), allow-listing identifiers like sort columns, and least-privilege database accounts.

Longer Answer

Escaping functions are error-prone; parameters keep data separate from code. ORMs are safe unless you use raw SQL with string formatting (text(f"... {x}"), whereRaw). Second-order injection stores malicious input that's later used unsafely. NoSQL databases have analogous operator-injection issues.

Code Example

-- Vulnerable (string concatenation)
query = "SELECT * FROM users WHERE email = '" + email + "'"

-- Safe (parameterized)
cursor.execute("SELECT * FROM users WHERE email = %s", (email,))

Key Points

• Parameterized queries
• Allow-list identifiers
• Beware raw SQL in ORMs
• Least-privilege DB users

Summary

Cross-Site Request Forgery tricks a logged-in user's browser into sending an unwanted state-changing request to your site, because browsers automatically attach cookies. Defend with SameSite cookies, anti-CSRF tokens, Origin/Referer checks, and never changing state on GET.

Longer Answer

Token-based APIs using the Authorization header aren't vulnerable because browsers don't attach those headers automatically. Frameworks include CSRF middleware (Django, Laravel, Spring Security, Flask-WTF).

Key Points

• Exploits automatic cookies
• SameSite=Lax/Strict
• Synchronizer or double-submit tokens
• Origin checks
• No state change on GET

Summary

A WAF inspects HTTP traffic (at a CDN, load balancer or reverse proxy) and blocks requests matching attack patterns (SQLi, XSS, known exploits), bad bots and abusive rates, using managed rule sets (e.g., OWASP Core Rule Set) and custom rules.

Longer Answer

WAFs are a valuable layer: they provide virtual patching for newly disclosed vulnerabilities, rate limiting, geo/IP rules and bot management. But they can't understand your business logic (IDOR, broken access control), can be bypassed by encoding tricks, and produce false positives that need tuning. Treat a WAF as defense in depth, not a substitute for secure code. Examples: AWS WAF, Cloudflare, Akamai, Azure Front Door/App Gateway WAF, ModSecurity/Coraza.

Key Points

• Filters malicious HTTP traffic
• Managed rules + custom rules
• Virtual patching, rate limits, bot control
• Can't fix authorization bugs
• Needs tuning for false positives

Summary

Fixed window counts requests per time window (simple, bursty at boundaries); sliding window smooths this by weighting the previous window or logging timestamps; token bucket refills tokens at a steady rate and allows bursts up to bucket capacity; leaky bucket processes requests at a constant rate.

Longer Answer

Distributed limits need a shared store (Redis with atomic Lua scripts) or edge enforcement. Return 429 Too Many Requests with Retry-After, and key limits by API key, user, IP (carefully behind proxies) or tenant.

Key Points

• Fixed window: simple, boundary bursts
• Sliding window: smoother
• Token bucket: controlled bursts
• Redis/edge for distributed limits
• 429 + Retry-After

Summary

SSRF happens when an attacker makes your server fetch a URL of their choosing, reaching internal services or cloud metadata endpoints (e.g., 169.254.169.254) to steal credentials. Prevent it by allow-listing destinations, resolving and blocking private/link-local IPs (including after redirects and DNS rebinding), and isolating fetchers.

Longer Answer

Features like URL previews, webhooks, image fetching and PDF rendering are common SSRF vectors. Use IMDSv2 on AWS (session tokens) to blunt metadata theft, disable redirects or re-validate them, and run fetchers in a network segment without internal access.

Key Points

• Server fetches attacker URLs
• Block private/metadata IPs
• Re-check after redirects/DNS
• Allow-list destinations
• IMDSv2 and network isolation