VAPT — Interview Prep¶
One-liner: A series of web-application Vulnerability Assessment & Penetration Testing engagements across four+ internet-facing apps, using OWASP ZAP, Nikto, Nmap, and Burp Suite — including authenticated scanning, OWASP Top 10 mapping, and remediation retests that show vulnerabilities being closed iteration over iteration.
1. Elevator pitch¶
30-second version:
"I ran VAPT engagements against several of our internet-facing applications. My workflow was layered: recon and port/TLS enumeration with Nmap, web-server scanning with Nikto, authenticated dynamic scanning with OWASP ZAP, and manual API testing with Burp Suite. I mapped findings to the OWASP Top 10 — the big ones were a SQL injection on an auth endpoint, path traversal, JWTs stored in browser localStorage, and a broad set of missing security headers and CSP issues. I then re-tested after fixes; you can see in the demo app reports that the XSS finding disappeared and the CSP findings became more granular as the team tightened the policy."
2-minute version adds the scope and the tool rationale (passive vs active scanning, authenticated context, false-positive triage on Nikto signature hits) covered below.
2. Scope & timeline¶
Engagement period: ~Nov 26, 2025 → Jan 1, 2026. Targets (from report filenames + contents):
| Host | Tool(s) | Date(s) |
|---|---|---|
| api.megafizz.questt.ai / megafizz.questt.ai | ZAP, Nikto | Dec 3–4, 2025 |
| stage.bpcl.questt.ai | ZAP, Nikto, Nmap | Dec 3, 2025 |
| api.morrie.ai / morrie.ai | ZAP, Nikto | Dec 12, 2025 (two runs) |
| api.demo.questt.ai / demo.questt.ai | ZAP, Nikto | Dec 30–31, 2025 + Jan 1, 2026 (three iterations = retests) |
| stage.api.hoad-bi.questt.ai (in Burp captures) | Burp | — |
The repeated demo.questt.ai reports (12-30, 12-31, 01-01) are iterative retests after fixes — a strong story about verifying remediation, not just finding bugs. The authenticated test account was vapt@questt.com (user "VAPT").
3. Tools used & why (know the differences cold)¶
| Tool | Type | Role in your workflow |
|---|---|---|
| Nmap 7.98 | Network recon | Port/service/OS discovery + NSE scripts: -A -Pn -T4, top-1000/5000 ports, --script vuln, ssl-enum-ciphers, http-enum/http-methods. Found ports 80/443, nginx 1.18.0/Ubuntu, TLS 1.2/1.3 all "A" ciphers |
| Nikto 2.5.0 | Web-server scanner | Server-level checks: outdated nginx, missing headers, signature-based legacy CVE probes. e.g. -host https://stage.bpcl.questt.ai -o nikto_report.html -Format html; 8129 requests, 10 findings |
| OWASP ZAP | DAST (app scanner) | Primary scanner — spider + passive (header/info-disclosure/tech-detection) + active scanning (Path Traversal, SQLi, persistent XSS, User-Agent fuzzer). Run with an authenticated session context |
| Burp Suite 2025.10.4 | Intercepting proxy | Manual API testing — request1 and sessionapi are Burp XML exports capturing authenticated traffic (JWT Bearer tokens, NextAuth session cookies), replaying /api/v1/daily-report, /api/auth/session |
Passive vs active scanning (you will be asked): Passive scanning only observes traffic the spider already generated — it flags missing headers, info leakage, tech fingerprints, cookie flags. It's safe and non-intrusive. Active scanning sends crafted attack payloads — SQLi strings, path-traversal sequences, XSS vectors — to confirm exploitable flaws. Active can be disruptive, so you run it against staging/with authorization.
SAST vs DAST: SAST analyzes source code statically; DAST (ZAP, Nikto) tests the running application from the outside. You did DAST + manual.
4. Methodology (the layered workflow)¶
- Recon / enumeration — Nmap for open ports (80/443), service/version (nginx 1.18.0/Ubuntu, on GCP), TLS cipher strength, OS fingerprint (Linux 4.19).
- Web-server scanning — Nikto for server misconfig and legacy signatures.
- Authenticated DAST — ZAP driven with a real session context (the
sessionapicapture shows a logged-innext-auth.session-token+ JWT for the VAPT user), so the scanner reaches authenticated endpoints, not just the login page. - Manual testing — Burp proxy to intercept/replay/manipulate authenticated API requests, confirm findings, and reduce false positives.
- Retest — re-run ZAP after the team remediates, compare reports.
Authenticated scanning matters — an unauthenticated crawl only sees the login wall. By giving ZAP a session context you scan the real application surface behind auth, which is where the high-value vulnerabilities (the SQLi auth endpoint, path traversal on signout) actually were.
5. Key findings (across reports)¶
Baseline misconfig present on nearly every target (OWASP A05 – Security Misconfiguration):
- CSP header not set (later: CSP wildcard directive, script-src/style-src 'unsafe-inline')
- Missing Anti-Clickjacking header (X-Frame-Options) — CWE-1021
- Missing Strict-Transport-Security (HSTS)
- Missing X-Content-Type-Options
- Server / X-Powered-By version leakage (info disclosure)
- Sensitive info in localStorage / sessionStorage
- Re-examine Cache-control, Suspicious Comments
- Many "Tech Detected" informational alerts (Next.js, NextAuth.js, Nginx, Tailwind, Express, Ubuntu, Radix UI)
High / Medium severity highlights:
| Host | High | Notable Medium/Low |
|---|---|---|
| api.megafizz | 0 High | 3 Medium incl. JWT in browser localStorage, CSP missing, clickjacking; Low incl. Vulnerable JS Library |
| stage.bpcl | 1 High — Path Traversal (POST /api/auth/signout, CWE-22, A01) |
App Error Disclosure, Big Redirect, sessionStorage leak, Cookie Poisoning |
| api.morrie | 2 High — SQL Injection (POST /api/v1/morrie-service/auth/validate, CWE-89, A03) + Vulnerable JS Library |
CSP, App Error Disclosure, clickjacking, Timestamp Disclosure |
| api.demo (12-30) | 1 High Path Traversal | Persistent XSS in JSON response |
| api.demo (12-31) | Path Traversal | CSP broken into granular findings; Persistent XSS (Low) |
| api.demo (01-01) | Path Traversal | 5 CSP/clickjacking Mediums; XSS gone (remediated) |
OWASP Top 10 (2021) mapping: A05 Security Misconfiguration (dominant), A01 Broken Access Control / Path Traversal, A06 Vulnerable/Outdated Components, A03 Injection (SQLi), A04 Insecure Design. CWEs: CWE-22 (path traversal), CWE-89 (SQLi), CWE-693 (protection mechanism failure), CWE-319 (cleartext transmission), CWE-1021 (clickjacking), CWE-525/615 (cookies).
Stack fingerprint: Next.js + NextAuth.js + Express behind nginx 1.18.0/Ubuntu on GCP.
6. Deliverables / artifacts¶
- 7 OWASP ZAP HTML reports (375 KB–1.16 MB) + asset folders.
- 4 Nikto HTML reports (megafizz, demo/morrie, stage.bpcl).
- 6 Nmap text outputs +
headers.txt(manual curl header inspection). - 2 Burp Suite XML exports (
request1,sessionapi) — authenticated request/response captures.
7. Interview Q&A¶
Q1. What is VAPT and what's the difference between VA and PT?
Vulnerability Assessment is breadth-first — automated scanning to enumerate as many weaknesses as possible (ZAP, Nikto, Nmap). Penetration Testing is depth-first — manually exploiting and chaining findings to prove real impact (Burp). VA tells you what might be wrong; PT confirms what an attacker can actually do. My engagements combined both.
Q2. Walk me through your methodology on an engagement.
Recon with Nmap (ports, services, TLS, OS), web-server scan with Nikto, authenticated dynamic scan with ZAP using a real session context, then manual verification and API manipulation with Burp, then a retest after fixes. Layered so each tool covers a different attack surface and I can cross-validate findings.
Q3. Passive vs active scanning — explain.
Passive scanning only inspects traffic already generated by the spider — it finds missing headers, info disclosure, cookie flags, tech fingerprints, and is safe to run anywhere. Active scanning injects attack payloads — SQLi, path traversal, XSS — to confirm exploitable bugs, which can be disruptive, so I run it against staging with authorization. ZAP's path-traversal/SQLi/XSS alerts came from active scanning.
Q4. How did you do authenticated scanning in ZAP, and why does it matter?
I configured ZAP with a session/authentication context using a valid login (the
vapt@questt.comaccount, captured as a NextAuth session token + JWT). Without that, the scanner only sees the public login page. With it, ZAP reaches the authenticated endpoints — which is exactly where the high-severity bugs were: the SQLi on/auth/validateand the path traversal on signout.
Q5. Tell me about the most serious finding.
SQL injection on the Morrie auth endpoint
POST /api/v1/morrie-service/auth/validate— CWE-89, OWASP A03. SQLi on an authentication endpoint is critical because it can lead to auth bypass or full DB compromise. I'd confirm it manually in Burp (e.g., boolean/time-based payloads) to rule out a false positive, and the fix is parameterized queries / prepared statements, never string-concatenated SQL.
Q6. JWT in localStorage — why is that a problem and what's the fix?
Tokens in localStorage are readable by any JavaScript on the page, so a single XSS flaw lets an attacker exfiltrate the token and hijack the session. The fix is to store the session token in an HttpOnly, Secure, SameSite cookie so JS can't read it, combined with a strong CSP to reduce XSS risk in the first place. It's a classic token-storage anti-pattern.
Q7. You found lots of "missing header" findings — are those actually important?
They're mostly Medium/Low individually but matter in aggregate as defense-in-depth. Missing CSP and X-Frame-Options enable XSS and clickjacking; missing HSTS allows protocol downgrade/SSL-strip; missing X-Content-Type-Options allows MIME sniffing. They're cheap to fix (header config) and meaningfully shrink the attack surface, so I always report them with concrete header values to set.
Q8. How do you handle false positives — Nikto especially?
Nikto is signature-based and noisy — it'll flag legacy Drupal/eZ-publish CVEs against an app that's actually Next.js. So I triage: cross-check against the real stack fingerprint from Nmap, manually verify in Burp, and only report what I can reproduce. A scanner result is a lead, not a confirmed vulnerability — manual confirmation is the PT part.
Q9. The demo app has three reports across three days — what's that about?
Those are remediation retests. After the team fixed issues, I re-ran ZAP and compared. You can see the progression: the persistent XSS finding disappears by Jan 1, and the CSP findings get more granular (from "CSP not set" to "wildcard directive / unsafe-inline") as they tightened the policy. Retesting closes the loop — finding a bug only matters if you verify the fix.
Q10. CSP findings evolved from "not set" to "unsafe-inline/wildcard" — explain.
Initially there was no Content-Security-Policy at all. Once they added one, the scanner started evaluating its quality and flagged weak directives —
script-src 'unsafe-inline'defeats much of CSP's XSS protection, and a wildcard source allows loading scripts from anywhere. So the remediation went from "no policy" to "a policy that still needs hardening" — progress, but not done. The fix is nonce/hash-based script-src and removing wildcards.
Q11. What's the difference between ZAP, Nikto, Nmap, and Burp?
Nmap = network layer: ports, services, TLS, OS. Nikto = web-server layer: server misconfig and signature CVE probes, fast but noisy. ZAP = application layer DAST: spider + passive + active scanning of the running app, scriptable and good for authenticated scans. Burp = manual intercepting proxy: the tool for hands-on request manipulation and confirming/exploiting findings. They're complementary layers, not substitutes.
Q12. How would you remediate the path traversal finding?
Path traversal (CWE-22) means user input reaches a filesystem path, so
../sequences escape the intended directory. Fix: never build file paths from raw input — canonicalize and validate against an allowlist, reject../, and use indirection (map an ID to a known file) instead of passing paths. The signout endpoint flagged here suggests a parameter being used in a file/redirect operation that needs validation.
Q13. How do you prioritize findings for the dev team?
By risk = likelihood × impact, anchored to OWASP/CWE severity. Highs first (SQLi, path traversal — exploitable, high impact), then Mediums that enable other attacks (CSP, clickjacking, token storage), then Low/Info hardening. I give each a clear repro, the affected endpoint, the OWASP/CWE reference, and a concrete fix, so devs can act without re-investigating.
Q14. How do you scope and stay authorized/legal in a pen test?
Written authorization and a defined scope (which hosts, which test types, time windows), testing against staging where possible, avoiding destructive/DoS techniques, and coordinating active scans so they don't take down production. The
stage.anddemo.targets show I worked against non-prod environments.
8. STAR story (memorize)¶
Situation: Several of our internet-facing apps (questt.ai brands, a BPCL staging app, morrie.ai) had never had a structured security assessment. Task: Find and prioritize web vulnerabilities and verify they got fixed. Action: I ran a layered VAPT — Nmap recon, Nikto server scan, authenticated ZAP DAST with a real session context, and manual Burp testing — mapped findings to the OWASP Top 10, and re-tested the demo app across three iterations as fixes landed. Result: I surfaced High-severity SQLi and path-traversal issues, a JWT-in-localStorage anti-pattern, and a broad header/CSP hardening gap; the retests confirmed the XSS was remediated and CSP was tightened — closing the loop from discovery to verified fix.
9. Key terms cheat sheet¶
- DAST/SAST/IAST — Dynamic (running app), Static (source), Interactive (instrumented runtime).
- OWASP Top 10 (2021) — A01 Broken Access Control, A02 Crypto Failures, A03 Injection, A04 Insecure Design, A05 Security Misconfiguration, A06 Vulnerable/Outdated Components, A07 Auth Failures, A08 Software/Data Integrity, A09 Logging/Monitoring Failures, A10 SSRF.
- CWE — Common Weakness Enumeration (CWE-89 SQLi, CWE-22 path traversal, CWE-79 XSS, CWE-1021 clickjacking).
- CVSS — scoring system that produces a 0–10 severity rating.
- Security headers — CSP, X-Frame-Options, HSTS, X-Content-Type-Options, Referrer-Policy, Permissions-Policy.
- Cookie flags — HttpOnly (no JS access), Secure (HTTPS only), SameSite (CSRF mitigation).