Comprehensive knowledge of common application and web security weaknesses and attack vectors across modern architectures and deployment models. Candidates should understand categories such as structured query language injection, command injection, cross site scripting, cross site request forgery, insecure deserialization, broken authentication and session management, broken access control, sensitive data exposure, insecure cryptography, security misconfiguration, using components with known vulnerabilities, insufficient logging and monitoring, race conditions, server side request forgery, xml external entity attacks, and business logic flaws. They should be able to explain attack mechanisms and exploitation techniques, give real world examples and business impact, and describe architectural and design level mitigations and secure patterns to reduce exposure. Familiarity with taxonomies and severity frameworks such as the Open Web Application Security Project Top Ten and the Common Weakness Enumeration, and an understanding of how prevalence and risk differ by application type, architecture, platform, and deployment pattern, is expected. Candidates should also know common assessment approaches and tooling such as vulnerability scanning, static application security testing, dynamic application security testing, and manual penetration testing.
MediumSystem Design
66 practiced
Lay out a pragmatic plan to integrate SAST, DAST, SCA, secret scanning, and manual penetration testing into a CI/CD pipeline for a fast-moving engineering organization. Include gating strategies, where to run expensive scans, reporting formats for developers, and ways to reduce noise and avoid blocking release velocity unnecessarily.
Sample Answer
**Clarify goals & constraints**- Fast delivery with measured risk reduction; low false positives; developer-friendly feedback; phased rollout.**High-level pipeline placement**- Pre-commit / local: SCA policies + fast secret-scanning IDE hooks and pre-commit hooks (prevent obvious leaks early).- PR (CI): Lightweight SAST incremental scans, SCA dependency checks, secret-scan full repo, linters. Block PRs for high/severe findings (CVE RCE, leaked creds).- Nightly / merge-to-main: Full SAST (deep), full DAST against ephemeral test env, container image SCA, SBOM generation. Report non-blocking medium findings.- Release / Pre-prod: Expensive penetration testing cadence (quarterly + major releases) and full DAST + interactive application security testing (IAST) if available. Critical fixes must clear before prod.**Gating & risk tiers**- Blockers: High confidence critical vulnerabilities, secrets, and certs. Fail fast in PR.- Harden warnings: Medium severity => create ticket + developer SLA but do not block merges initially.- Informational/low: Only visible in dashboards to reduce interruptions.**Where to run expensive scans**- Isolated ephemeral test environments and dedicated scan runners (cloud instances with resource quotas). Schedule during off-peak and on merge-to-main to avoid CI latency.**Reporting for developers**- Single actionable issue per finding: vulnerability, location, reproducible steps, suggested fixes, links to internal policy, CVE references.- Integrate with dev tools: GitHub/GitLab code annotations, Slack/Teams summary, Jira auto-create for high/critical.- Triage view in centralized dashboard with risk scoring and owner assignment.**Noise reduction**- Triage rules: suppress false positives via allowlists scoped to paths, mark findings as accepted risk with expiry, dedupe across scans, baseline existing legacy findings with remediation plans.- Use bloom filters/affinity to ignore scanned third-party code directories.- Tune SCA severity threshold and use automated version bump PRs for low-risk CVEs.**Governance & metrics**- KPIs: time-to-remediate critical, scan coverage, false-positive rate, blocked releases due to security.- Run retros every quarter to adjust thresholds and move items from non-blocking to blocking as maturity grows.This plan balances fast delivery and robust security by shifting cheap feedback earlier, running heavy scans off the critical path, and giving developers clear, prioritized, low-noise actions.
HardTechnical
88 practiced
A malicious npm package was published and pulled transitively into your build pipeline and production images. Describe an immediate remediation and longer-term prevention plan covering containment, SBOM updates, SCA findings, artifact rebuild and redeploy, dependency pinning and lockfile policies, package signing and verification, and governance changes to reduce supply chain risk.
Sample Answer
**Immediate containment (0–24 hrs)** - Revoke and isolate: Block the malicious package and any known versions in the internal artifact registry and CI/CD upstream mirrors (npm proxy). - Stop deploys: Pause pipelines that pull fresh dependencies; prevent new image builds. - Identify blast radius: Use SCA results, SBOMs, and build logs to enumerate images, services, and environments that include the package transitively. - Short-term mitigation: Apply runtime controls (WAF, egress deny-lists, host isolation) for affected services.**Remediation (24–72 hrs)** - Update SBOMs: Regenerate SBOMs for affected images and store immutable copies. Mark compromised components. - SCA findings: Triage and prioritize findings; escalate to owners for remediation tickets. - Artifact rebuild & redeploy: Rebuild artifacts after removing or replacing the malicious dependency; sign and publish new artifacts to trusted registries; redeploy to replace compromised instances. Verify runtime integrity after deployment.**Longer-term prevention (weeks → months)** - Lockfiles & pinning: Enforce lockfile usage (package-lock.json / yarn.lock) in CI; require installation from lockfile only. Enable deterministic builds and CI policy to prevent lockfile drift. Prefer pinned versions for direct deps and semver-ranged policies for vetted libs. - Package signing & verification: Adopt package/source signing (sigstore for containers and binaries, npm package signing where available). Verify signatures in CI and fail builds when signatures are missing or invalid. - Harden SCA & SBOM pipeline: Automate SBOM generation at build time; integrate SCA with gating rules (block high/critical malware or risky transitive deps). Maintain a trusted whitelist and automated alerting. - Artifact provenance: Record build provenance (who, when, inputs) and store in immutable registry with signatures. - Governance and process: Create a supply-chain policy: dependency review board, mandatory security review for new dependencies, risk thresholds, and incident playbooks. Require third-party risk assessments for critical packages and vendor SLAs. - Developer education & incentives: Train teams on secure dependency hygiene, encourage minimal dependency principles, and run periodic dependency audits. - Continuous monitoring: Monitor public advisories, CVEs, and threat intelligence feeds; integrate into ticketing and CI. This plan balances urgent containment, verified remediation, and engineering controls plus governance to materially reduce future supply-chain risk.
MediumTechnical
67 practiced
For a payment application subject to PCI-DSS and GDPR, map key OWASP Top Ten weaknesses and relevant CWE categories to specific controls and evidence you would present during audits (for example encryption controls, access control policies, logging and retention artifacts). Propose monitoring and automated evidence collection to maintain continuous compliance.
Sample Answer
**Approach (Security Architect lens)** I map each OWASP Top Ten item to concrete controls, related CWE(s), sample audit evidence, and automated monitoring/evidence collection so auditors and ops teams can validate continuous PCI-DSS & GDPR compliance.**Mappings — examples**- Injection (OWASP A1) → CWE-89 - Controls: Parameterized queries, ORM use, input validation, DB least privilege. - Evidence: Code snippets, DB role policies, prepared-statement unit tests, static analysis (SAST) findings, PR review logs. - Automation: CI pipeline SAST + dependency check; daily fail-build if new critical CWE-89 found; artifacts pushed to compliance repo.- Broken Authentication/Session Management (A2) → CWE-287, CWE-306 - Controls: MFA, secure cookie flags, short session TTL, auth token rotation, account lockout. - Evidence: IAM policy export, MFA enrollment reports, config of session settings, access-review logs. - Automation: Periodic IAM inventory, automated attestations, alert on auth config drift via infra-as-code tests.- Sensitive Data Exposure (A3) → CWE-200, CWE-311 - Controls: TLS 1.2+/HST S, field-level crypto with HSM, tokenization for PAN, data minimization (GDPR). - Evidence: HSM key lists, KMS policies, TLS scan reports, encryption-at-rest/in-transit configs, data-flow diagrams, DPIA. - Automation: Continuous TLS/KMS scans, automated proof-of-encryption checks, key-rotation logs.- Broken Access Control (A5) → CWE-284, CWE- bypass patterns - Controls: RBAC/ABAC, authorization tests, deny-by-default, horizontal/vertical access tests. - Evidence: Authz matrix, automated integration tests, penetration test results, recent access reviews. - Automation: Weekly authz security tests (API fuzzing), SIEM alerts for privilege escalation attempts.- Security Misconfiguration (A6) → CWE-16 - Controls: Hardened images, IaC templates, immutable infra, secure defaults. - Evidence: Baseline images, CMDB, IaC PR history, hardened checklists. - Automation: Drift detection (Terraform plan diffs), CIS benchmark scans, auto-remediation playbooks.- Insufficient Logging & Monitoring (A10) → CWE-778/other - Controls: Centralized logging (SIEM), WAF, EDR, retention aligned with PCI & GDPR minimization. - Evidence: SIEM rule set, sample alerts, retention policy, archived logs, SOC runbooks. - Automation: Log-forwarders health checks, retention enforcement scripts, automated export of daily SOC metrics for auditors.**Monitoring & Automated Evidence Collection**- CI/CD gates: enforce security tests (SAST/DAST/SCA), produce immutable reports stored in compliance bucket with checksums. - Configuration-as-code tests: nightly IaC policy scans (OPA/Conftest), drift alerts, auto-issue tickets. - SIEM + SOAR: auto-generate incident timelines, executive KPI dashboards, retention & redaction workflows for GDPR. - Compliance dashboard: consolidated artifacts (scan reports, key rotation, IAM attestations, pentest findings) with timestamps and cryptographic hashes for tamper-evidence. - Playbooks: automated evidence bundles for audits (zip of relevant configs, logs, test outputs) generated on-demand.**Trade-offs & rationale**- Balance evidence retention (PCI retention requirements) with GDPR minimization by tokenizing PII and storing audit hashes instead of raw PII. - Prefer automation to reduce human error, but retain manual review checkpoints for high-risk exceptions.This mapping ties developer controls, infra configuration, and operational monitoring to verifiable artifacts auditors expect while keeping GDPR data-minimization and PCI cryptographic controls central.
EasyTechnical
60 practiced
Describe the types of Cross-Site Scripting (reflected, stored, DOM-based), how each is typically exploited in modern single-page applications, concrete coding and architectural mitigations (context-specific output encoding, safe templating, CSP, sanitizers), and caveats when third-party scripts are present.
Sample Answer
**Types & modern exploitation**- **Reflected XSS**: attacker-supplied input is immediately returned (e.g., search/query param). In SPAs this often occurs when routers render URL fragments or query strings into the DOM without encoding. Exploited via phishing links that cause the victim’s browser to run injected script.- **Stored XSS**: payload persisted (comments, user profiles, DB). In SPAs, payload can be stored server-side or in third-party services and later rendered by client code.- **DOM-based XSS**: the vulnerability is purely client-side — scripts read location.hash, location.search, or postMessage and write into innerHTML, eval, or dangerous sinks. Very common in SPAs that manipulate the DOM and templates client-side.**Concrete coding & architectural mitigations**- Context-specific output encoding: HTML-encode for insertion into HTML, attribute-encode for attributes, JS-encode for inline scripts, URL-encode for URIs. Enforce via libraries (OWASP Java Encoder, DOMPurify for specific contexts).- Safe templating: use frameworks’ safe binding (e.g., React JSX, Angular binding) which auto-escape; avoid dangerouslySetInnerHTML or ng-bind-html without sanitizer.- CSP: deploy strict Content-Security-Policy with disallow 'unsafe-inline', use nonce-based script execution, restrict script-src to trusted origins. Add report-uri/report-to for monitoring.- Sanitizers: use vetted libraries (DOMPurify) configured to allow only required tags/attributes; validate server-side too.- Input validation & server-side output encoding: treat client as hostile, canonicalize and validate on server; persist safe representation.- Secure defaults: automated scanning in CI, security linting, dependency checks.**Caveats with third-party scripts**- Third-party scripts inherit DOM privileges — if they are compromised they can bypass CSP unless CSP restricts their origin. Use Subresource Integrity (SRI) for static scripts, isolate with Trusted Types and strict CSP, load untrusted widgets inside sandboxes/iframes with appropriate sandbox attributes and postMessage boundaries.- Monitor and minimize third-party usage, apply allowlists, and use runtime integrity checks and behavioral monitoring.I would implement these controls in policy: secure-by-default frameworks, CSP + Trusted Types, CI checks, and isolation patterns for third-party code.
HardTechnical
86 practiced
Design a detection strategy that enables the SOC to rapidly identify and triage application-layer attacks including SQLi, XSS, SSRF and insecure deserialization. Specify which log sources to collect, detection heuristics and rules, anomaly-detection approaches, alert prioritization factors, and feedback loops to engineering for tuning and remediation.
Sample Answer
**Situation / Goal**Design a SOC-facing detection strategy to rapidly identify/triage application-layer attacks (SQLi, XSS, SSRF, insecure deserialization) that is practical at enterprise scale and actionable for engineering.**Log sources to collect**- Web server access logs (URL, query, headers, user-agent, referrer, response code, latency)- Application logs (parameter values, stack traces, deserialization errors, auth events)- WAF/NGFW logs (rule hits, request body inspection)- RASP/agent telemetry (runtime exceptions, object graph anomalies)- API gateway / load balancer logs (rate, client IP, JWT claims)- Host EDR / process logs for unusual child processes or binds- Threat intel feeds (IP reputation, payload signatures)**Detection heuristics & rules**- SQLi: suspicious SQL keywords in params combined with tautologies, comment chars, time-based functions; high error-rate returning DB errors; blind-SQL timeouts from specific client.- XSS: script tags, event handlers, encoded payloads in params/referrer; DOM-sourced stack traces; reflected output mismatch.- SSRF: outbound connection attempts originating from web process to internal IP ranges or metadata endpoints; unusual DNS queries.- Insecure deserialization: deserialization exceptions, class name patterns in inputs, sudden invocation of gadgets, unexpected object creation.- Correlate multi-evidence: same IP + multiple distinct attack heuristics within short window → higher severity.**Anomaly detection approaches**- Baseline per-app: model normal URL parameter patterns (n-gram/token models), typical payload entropy, and request rates per client.- UEBA: user-session anomaly scoring (new geo, credential reuse, abnormal sequence of endpoints).- ML-based payload anomaly: autoencoders for request body/token embeddings to flag high-reconstruction-error inputs.- Drift detection to capture changes after deployments.**Alert prioritization factors**- Evidence strength (confirmed exploit vs suspicious): rule score weights- Asset criticality (public API, auth endpoints, payment flows)- Access context (authenticated user, admin role)- Lateral risk (attempts to internal IPs, metadata endpoints)- Exploitability & impact (RCE vs reflected XSS)- Confidence & corroboration (WAF hit + app error + EDR process spawn)**Feedback loops to engineering**- Ticket with reproducible steps, sanitized payload, relevant logs, timeline, suggested fixes (input validation, prepared statements, output encoding, blocklist/allowlist, stricter deserialization policies)- Post-incident RCA with priority backlog items and regression tests- Weekly tuning: false-positive metrics, rule thresholds, model retraining cadence- CI integration: pre-prod RASP/WAF simulation and synthetic attack injection (canary tests) to validate detections- SLA for remediation and verification scan after fixesThis strategy balances deterministic rules for high-confidence alerts with behavioral models to catch novel attacks, and embeds continuous feedback to reduce noise and harden applications.
Unlock Full Question Bank
Get access to hundreds of Application and Web Vulnerabilities interview questions and detailed answers.
