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

40 practiced

List three common logging and monitoring gaps you prioritize during a penetration test (e.g., missing context, retention gaps, no alerting). For each gap provide a concrete runtime detection or logging improvement that reduces the chance of undetected exploitation.

MediumTechnical

38 practiced

A JSON-based API echoes a user-supplied parameter into a JavaScript client response. Describe how to test for DOM-based XSS in this SPA: include instrumentation techniques (browser devtools, Burp extension, automated DOM sinks scanning), safe proof-of-concept skeleton payloads, and how you would triage and classify the issue.

Sample Answer

**Approach overview**I’d confirm DOM‑XSS by reproducing how the SPA consumes the JSON parameter in the client and showing a safe, non‑destructive PoC that reaches a DOM sink. I combine browser instrumentation, active proxy manipulation, and automated scanning of DOM sinks.

**Instrumentation & testing techniques**- Browser DevTools: set breakpoints (Event Listener, XHR/fetch, DOM mutation) and use Snippets/Console to inspect where JSON value is assigned (innerHTML, insertAdjacentHTML, eval, new Function, location/hash).- Burp Suite: intercept JSON response, modify parameter, and observe client behavior. Use Burp Repeater + Collaborator if callbacks needed.- Burp Extender: install DOM Invader or write a small extension to inject payloads and detect sink execution.- Automated scanning: run tools (DOMinator, DOM XSS Scanner) to enumerate sinks, then manually verify high‑risk findings.

**Safe PoC skeleton payloads**Use inert payloads that announce execution via visible DOM change or console log to avoid harming users:

html

<img src=x onerror="console.log('DOMXSS:'+location.href)">

If client sanitizes tags, use JS URL patterns:

html

javascript:console.log('DOMXSS:'+document.cookie)

Or attribute-based:

html

" onmouseover="console.log('DOMXSS')//

Send as JSON value and observe the Console/DOM mutation or network callbacks.

**Triage & classification**- Confirm exploitability: uncontrolled insertion into a DOM sink reachable to attacker-controlled input without server-side encoding.- Classify severity by attacker context: reflected into page visible to victim (High), exploitable via CSRF or stored for many users (Critical), or only in non‑privileged sandboxed context (Low).- Recommend fixes: use proper output encoding (contextual escaping), avoid innerHTML/eval, use safe APIs (textContent, setAttribute with safe values), CSP and input validation.- Report includes steps to reproduce, proof-of-concept payload, remediation, and risk impact.

HardTechnical

36 practiced

In a red-team exercise you chain SSRF -> internal port scan -> exposed management interface to achieve admin access in a cloud environment. Describe how you would safely perform the chain (scope, safety controls), how to document reproducible steps and evidence, and how to prioritize mitigations (short-term runtime controls vs long-term architectural changes).

Sample Answer

**Situation & Scope (safety first)** - Confirm written authorization: scope, dates, targets, non-target exclusions (production customer data, backups, third-party systems). - Define blast radius limits: max concurrent probes, time windows, rollback/kill-switch contacts. - Safety controls: use isolated tester IPs, rate-limit scans, non-destructive payloads, monitoring hooks, and a notify-and-stop channel with ops.

**Safe execution of chain** - SSRF: use safe payloads that only probe metadata endpoints; avoid destructive methods. Record HTTP request/response. - Internal port scan: prefer TCP SYN or application-level probes with low rate and jitter; use nmap with --min-rate and --max-retries, or a custom script to avoid flooding. - Management interface access: prefer read-only interactions; do not change configs or escalate—capture screenshots, API responses.

Example probe (non-destructive):

bash

# safe HTTP probe via SSRF redirect (example)
curl -s -o /dev/null -w "%{http_code}" "https://vulnerable.example/redirect?url=http://169.254.169.254/latest/meta-data/"

**Documentation & reproducible steps** - Provide step-by-step: prerequisites, exact requests (raw HTTP), timing, headers, attacker IP, and tools/versions. - Include artifacts: pcap, full HTTP logs, nmap XML, screenshots, timestamps, and hashes. Supply a trimmed, annotated PoC script that reruns probes at safe rates.

**Mitigation prioritization** - Short-term runtime: block SSRF sinks with allowlist, egress filtering to internal ranges, WAF rules, metadata service IMDSv2 enforcement. (Immediate, high ROI.) - Long-term architectural: eliminate direct management interfaces on internal networks, network segmentation, zero-trust, least-privilege instance roles, centralized proxying and auditing. (Strategic, durable.)

**Risk & remediation mapping** - Map each finding to impact (confidentiality/integrity/availability), exploitability, and recommend urgency (Immediate/High/Medium). Provide validation steps for fixes.

EasyTechnical

41 practiced

Explain how weak cryptography and data integrity failures manifest in web applications. Provide short examples for: (a) password storage, (b) session token construction, (c) data-at-rest encryption, and (d) message integrity checks. For each example list recommended algorithms and why common older algorithms are unsafe.

HardSystem Design

32 practiced

Design an automated CI/CD merge gate that prevents new code introducing OWASP Top Ten vulnerabilities. Describe the combination of static checks, dependency (SCA) scans, unit/integration tests, policy-as-code (e.g., OPA), and human review steps. Recommend specific tooling (e.g., GitHub Actions, SonarQube, Snyk) and a strategy to handle false positives and developer workflow friction.

Sample Answer

**Clarify goals & constraints**Block merges that introduce OWASP Top Ten risk while minimizing developer friction and allowing pen-test validation. Gate must combine SAST, SCA, runtime tests, policy-as-code and human triage.

**High-level flow**- Pull request triggers GitHub Actions pipeline.- Fast pre-merge checks (seconds–minutes): incremental SAST (SonarQube/SonarCloud), SCA (Snyk/Dependabot alerts), linting, secret scan (GitLeaks).- Medium checks (minutes): unit tests + targeted integration tests exercising auth/session/inputs; infrastructure-as-code scans (tfsec/checkov).- Policy evaluation: Rego policies in OPA/Gatekeeper run as part of CI to enforce risk thresholds and blocking rules.- Evidence & human review: If automated findings exceed policy, open a security review ticket with repro steps, PoC snippets, and recommended fixes. Security reviewer (or peer) validates; pen-tester can be assigned to verify exploitability if needed.

**Tooling recommendations**- Orchestration: GitHub Actions for native PR checks.- SAST: SonarQube + GitHub Code Scanning (CodeQL) for coverage.- SCA: Snyk (dev-friendly fix PRs) + Dependabot for automatic updates.- Secrets/IaC: GitLeaks, tfsec, checkov.- Policy-as-code: OPA with Rego policies stored in repo; evaluate in Actions using open-source OPA CLI.- Triage/UI: GitHub Security Advisory + Jira integration for human workflow.

**False positives & developer friction**- Use incremental, fast scans on diffs to reduce noise.- Configure severity thresholds in OPA (allow medium to be advisory).- Auto-create annotated PR comments with exact file/line, reproducer, and suggested fix snippets; include "Accept Risk" workflow requiring security owner sign-off.- Snyk/Sonar suggested-fix PRs reduce manual patching.- Maintain a whitelist and exclude rules under versioned policy-as-code; each exclusion requires ticket and TTL.- Regular calibration sprints where pen-testers validate common findings and update rules/signatures.

**Pen-tester role**- Provide PoC exploit templates used by CI tests to validate true positives.- Periodically run red-team style PR validations to surface chain vulnerabilities not caught by static checks.- Feed findings back into Rego policies and test-suite to reduce recurrence.

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.