Web Security
Web applications are the largest attack surface in the world — every company exposes one to the public internet. The OWASP Top 10 are not theoretical risks, they are the exact vulnerabilities being exploited in production systems right now.
Intermediate
OWASP Top 10
The 10 most critical web application security risks — injection, broken auth, XSS, and the rest. Every web developer must know these.
Beginner
SQL Injection
The most common critical vulnerability. How it works, how attackers use it, and how to prevent it with parameterised queries.
Intermediate
XSS & CSRF
Cross-site scripting and cross-site request forgery — injecting malicious scripts and forging user requests.
Intermediate
Auth Vulnerabilities
Broken authentication, session fixation, JWT attacks, and the security mistakes that expose user accounts.
Intermediate
Burp Suite
The industry-standard web application security testing platform. Intercept, replay, and fuzz HTTP requests.
Intermediate
API Security
Securing REST and GraphQL APIs — rate limiting, input validation, authentication, and common API attack vectors.
Advanced
SSRF, XXE & Request Smuggling
Server-Side Request Forgery, AWS IMDSv2, XML External Entities, and HTTP desync request smuggling.
Intermediate
Subdomain Takeover & Web Recon
Dangling CNAME auditing, S3/GitHub Pages takeover vectors, virtual host brute-forcing, and web OSINT.
Interview Scenarios
Real-world questions for Web Security
1If an application is vulnerable to Blind SQL Injection where no SQL errors are returned, how do you extract data?
Use Time-Based or Boolean-Based Blind techniques. In Time-Based Blind SQLi, inject conditional database delays (e.g.
1 AND (SELECT IF(SUBSTRING(password,1,1)='a', SLEEP(5), 0)) FROM users --'). Measure HTTP response latency to infer character by character. To fix: Never concatenate input into raw SQL strings; always use parameterized queries / prepared statements ('db.query(SELECT * FROM users WHERE id = ?, [userId])').2How do you mitigate a Stored XSS vulnerability in a modern web application?
1. Context-Aware Output Encoding: Encode HTML, attribute, and JavaScript contexts before rendering user input. 2. Implement a strict Content Security Policy (CSP) header: 'Content-Security-Policy: default-src
self; script-src self;'. 3. Set HttpOnly and SameSite=Strict flags on authentication cookies so injected scripts cannot access document.cookie.3How do you exploit and patch a JWT 'alg: none' vulnerability?
Exploit: Change the JWT header to
{"alg":"none","typ":"JWT"}, strip the signature, and send the modified payload. If the backend fails to enforce signature verification algorithms, it accepts the forged token as valid. Fix: Explicitly whitelist expected signature algorithms on the backend (e.g. 'jwt.verify(token, secret, { algorithms: [HS256] })') and reject tokens with alg: none.4How do you defend a web application against Cross-Site Request Forgery (CSRF)?
1. Anti-CSRF Tokens: Implement unique, cryptographically secure synchronizer tokens per user session that are validated on all state-changing requests (POST, PUT, DELETE). 2. SameSite Cookie Attribute: Set
SameSite=Lax or SameSite=Strict on all session cookies to prevent cross-site request inclusion. 3. Custom Request Headers: Require a custom header (e.g. X-Requested-With) for API endpoints.5If an attacker leverages Server-Side Request Forgery (SSRF) to target cloud instance metadata (169.254.169.254), how do you fix it?
1. Cloud Hardening: Enforce IMDSv2 (Instance Metadata Service Version 2) on AWS, requiring session tokens via PUT requests. 2. Input Validation: Validate and sanitize all user-supplied URLs, blocking private IP ranges (
127.0.0.1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.169.254). 3. Network Egress Rules: Restrict web application outbound network egress to explicitly required external domains.6How do you identify and resolve Insecure Direct Object Reference (IDOR) vulnerabilities in REST APIs?
Identify: Change object identifier parameters in requests (e.g. GET /api/documents/1042 -> /api/documents/1043) and test if unauthorized data is returned. Fix: Implement robust server-side authorization checks on every resource request: verify that the authenticated user ID matches the owner ID of the requested resource in the database before returning data.
7How do you prevent Mass Assignment / Over-Posting vulnerabilities when binding JSON request bodies to database models?
Prevent attackers from injecting administrative attributes (e.g.
"is_admin": true) by avoiding direct binding of raw JSON payloads to ORM models. Instead, use explicit Data Transfer Objects (DTOs) or strict schema validators (e.g. Pydantic / Zod) that whitelist only permitted user-updatable fields.8If an XML parser is vulnerable to XML External Entity (XXE) Injection, how do you prevent file read or SSRF exploits?
Disable DTD (Document Type Definition) evaluation and external entity resolution in your XML parser configuration. For example, in Python: use
defusedxml instead of standard xml.etree, or set parser = etree.XMLParser(resolve_entities=False) in lxml.9How do you diagnose and fix a CORS misconfiguration allowing credentialed cross-origin access?
Diagnose: Look for wildcard
Access-Control-Allow-Origin: * combined with Access-Control-Allow-Credentials: true or dynamic reflection of the Origin request header in responses. Fix: Configure explicit, whitelisted origin domains instead of reflecting request headers, and never set wildcard origins when credentials are allowed.10How do you implement API Rate-Limiting to stop credential stuffing and brute-force attacks?
Deploy a distributed rate-limiter using Redis (Token Bucket or Sliding Window Algorithm) at the API Gateway / Reverse Proxy layer (e.g. Nginx
limit_req_zone or Cloudflare WAF). Enforce strict per-IP and per-account limits (e.g. 5 failed login attempts per minute per IP).