XSS
Client-side
Cross-Site Scripting
Q. What is XSS, and how do you distinguish reflected, stored, and DOM-based?
A. XSS runs attacker script in the victim’s browser under your origin. Reflected returns in the same response; stored is persisted (comment/profile) and hit later; DOM-based happens when client JS writes attacker data into a dangerous sink without a classic server reflection.
How to test / practice
- Map every input that reaches HTML, attributes, JS, or URL sinks.
- Probe with harmless canaries first, then context-aware payloads (HTML body vs attribute vs JS string).
- Check encoding, CSP, cookie flags, and whether HttpOnly blocks token theft.
- Retest after fix: encoding + CSP + framework escaping — not only blocking <script>.
Pro tip: In interviews, draw the data flow on a notepad: source → encoding → sink. Interviewers hire the method, not the payload.
Live scenario: You find a search box that echoes <?php echo $_GET["q"]; ?> into HTML. How do you prove impact without dumping cookies in production?
Why it matters: Session theft, account takeover, malware drive-by inside the authenticated app.
STAR
Behavioral
Stored XSS you reported under pressure
Q. Tell me about a time you found a high-impact client-side issue and had to convince engineering to fix it fast.
A. Use STAR. Keep under 90 seconds, then offer depth if they ask.
STAR answer
S — Situation — Product launched a new “rich bio” field. Support saw odd pop-ups; no security ticket yet.
T — Task — Confirm whether it was stored XSS, prove impact safely, and get a fix prioritized before marketing demos.
A — Action — Reproduced with a harmless alert canary in a staging account, showed session risk with HttpOnly gaps, wrote a one-page report with root cause + CSP/encoding fix, joined a 15-min huddle with the FE lead.
R — Result — Fix shipped in 48 hours, CSP tightened, regression test added. Demo week stayed clean; you documented a reusable checklist.
How to test / practice
- How to test like this again: create two users, post bio as A, view as B.
- Try SVG/markdown contexts if the editor allows HTML subsets.
- Validate fix with the original canary + a DOM sink check in DevTools.
Pro tip: Never lead with the scariest payload. Lead with business risk (“demo takeover”) and a safe PoC.
Live scenario: Manager says “just strip script tags.” Your next sentence?
Why it matters: Shows collaboration + technical depth — what hiring managers actually score.
SSRF
Server-side
Server-Side Request Forgery
Q. How would you test a “fetch URL / webhook / import from URL” feature for SSRF?
A. SSRF makes the server request a URL you influence — often toward internal hosts, cloud metadata, or admin ports. Interview answer: show allowlist thinking and a test plan, not a single magic IP.
How to test / practice
- Inventory URL-taking features: previews, PDF generators, webhooks, avatar-by-URL.
- In authorized labs only, try loopback / link-local / metadata endpoints that are in scope.
- Follow redirects; note DNS rebinding and alternate schemes only if policy allows.
- Recommend allowlists, block private ranges, disable weird schemes, authenticate egress.
Pro tip: Say out loud: “I treat SSRF as an egress control problem first.” That sounds senior.
Live scenario: Feature fetches https://example.com/image.png. What do you try next in a lab, step by step?
Why it matters: Internal port scan, cloud credential theft via metadata, pivoting to admin panels.
STAR
Behavioral
SSRF near cloud metadata
Q. Describe a time you found a server-side request issue and handled scope carefully.
A. STAR format — emphasize ethics and communication.
STAR answer
S — Situation — PDF “render from URL” feature in a staging app hosted on a cloud VM.
T — Task — Determine if the renderer could hit internal services without exceeding authorized scope.
A — Action — Confirmed basic SSRF to an in-scope canary host you controlled, documented redirect behavior, paused before metadata probes until written approval, looped in the cloud owner.
R — Result — Feature switched to allowlisted CDN hosts; egress firewall rules added. You earned trust for safe testing habits.
How to test / practice
- How to test: start with a collaborator/canary URL you own.
- Log status codes and response body size differences.
- Only escalate to sensitive targets with explicit authorization.
Pro tip: Interview gold: “I stopped and asked for scope expansion.” Shows judgment.
Live scenario: Recruiter asks if you ever hit 169.254.169.254. How do you answer honestly?
Why it matters: Judgment under pressure — critical for consulting roles.
CSRF
Client-side
Cross-Site Request Forgery
Q. When is CSRF still relevant, and what is a solid mitigation story?
A. CSRF tricks a logged-in browser into a state-changing request the user did not intend. Highest risk: cookie sessions without anti-CSRF tokens or SameSite discipline.
How to test / practice
- List cookie-auth state changes (POST/PUT/DELETE).
- Check synchronizer tokens, double-submit cookies, Origin/Referer checks.
- Verify SameSite and whether CORS + credentials widen abuse.
- Fix: tokens + SameSite + never use GET for state changes.
Pro tip: If the API is Bearer-token in Authorization header (not cookies), say why classic CSRF risk drops — then mention XSS still wins tokens.
Live scenario: Email-change endpoint accepts POST with only session cookie. Walk the PoC HTML form you would build in a lab.
Why it matters: Forced email swap, password change, OAuth app grants.
IDOR
Server-side
Insecure Direct Object Reference
Q. How do you explain IDOR and prove it in a real test?
A. IDOR is broken access control: the app trusts an object ID without checking if your user may access it. Classic: /api/orders/1001 → 1002 returns another user’s order.
How to test / practice
- Create users A and B. Capture A’s object IDs.
- Replay as B (and anonymous) swapping IDs — horizontal and vertical.
- Focus on authorization, not only UUID obscurity.
- Fix: server-side authZ on every object; ownership checks always.
Pro tip: Automate with a simple repeater checklist: list → detail → update → delete for each ID.
Live scenario: GraphQL returns other users’ emails when you change the id argument. How do you report severity?
Why it matters: PII leak, invoice theft, ATO chains.
STAR
Behavioral
IDOR that others missed
Q. Tell me about a vulnerability others missed and how you investigated.
A. STAR — show curiosity and method.
STAR answer
S — Situation — Team finished a DAST scan with “clean” results on an API.
T — Task — Manual authZ pass before release.
A — Action — Built two accounts, mapped every IDOR-prone resource, found export endpoint that skipped ownership on UUID, wrote reproduction with Burp, proposed middleware authZ helper.
R — Result — Blocking bug fixed pre-prod; added automated twin-user tests in CI for top 10 resources.
How to test / practice
- How to test: never trust “UUID = secure.”
- Compare responses byte-size and fields, not only status 200 vs 403.
- Ask for twin accounts early in every engagement.
Pro tip: End with the system change (CI test), not only the bug — that is “senior.”
Live scenario: Lead says scanners already ran. Your reply in one sentence?
Why it matters: Manual creativity + engineering partnership.
SQLi
Server-side
SQL Injection
Q. Walk through how you confirm and report SQL injection safely.
A. SQLi is untrusted input concatenated into a query. Emphasize detection method, impact framing, and parameterized queries — not dumping production data.
How to test / practice
- Find injectable points in labs/in-scope targets (search, filters, headers).
- Prefer boolean/time differentials that are non-destructive.
- Note DBMS hints only if disclosed; stay inside authorization.
- Fix: parameterized queries / ORM binds + least-privilege DB accounts.
Pro tip: Interview line: “My goal is a safe proof and a developer-ready fix, not a data dump.”
Live scenario: Filter parameter sorts by column name. How do you test for injection vs only ORDER BY abuse?
Why it matters: Data exfil, auth bypass, rare RCE via DB features.
XXE
Server-side
XML External Entity
Q. When should you look for XXE, and what fix do you recommend?
A. XXE abuses XML parsers that resolve external entities — file read or SSRF-like fetches. Hunt anywhere XML/SOAP/SAML/SVG/Office XML is parsed.
How to test / practice
- Identify XML upload or body parsers.
- In labs, test entity expansion with harmless canaries.
- Check whether DTDs / external entities are disabled.
- Fix: disable DTDs & external entities; prefer JSON; patch libraries.
Pro tip: Mention billion-laughs DoS so they know you think about availability too.
Live scenario: App accepts SVG avatars. What is your first XXE-oriented check?
Why it matters: Local file disclosure, internal SSRF, DoS.
Upload
Server-side
File upload vulnerabilities
Q. How do you test an upload feature like a professional assessment?
A. Unsafe uploads can become webshells, stored XSS (SVG/HTML), or path overwrite. Checklist: type, content, path, execution context.
How to test / practice
- Check extension, MIME, magic-bytes, double extensions (lab only).
- See if files are served executable or with dangerous Content-Type.
- Test path traversal in filenames if user-controlled.
- Fix: allowlist, random names, separate bucket/domain, re-encode images, no exec.
Pro tip: Always ask: “Where is this file stored and who can request it?”
Live scenario: Upload accepts .png only by extension. What bypasses do you try in a safe lab?
Why it matters: RCE, malware hosting, stored XSS via SVG.
Redirect
Client / Server
Open redirect
Q. Why do open redirects matter in interviews and bounty work?
A. They bounce users through a trusted domain to an attacker site — useful for phishing and sometimes OAuth/token theft chains.
How to test / practice
- Find ?next= / returnUrl / SSO callbacks.
- Test absolute, protocol-relative, and encoded bypasses.
- Think OAuth redirect_uri confusion.
- Fix: allowlist destinations or internal route IDs — never raw URLs.
Pro tip: Severity depends on chain potential — explain phishing vs direct RCE honestly.
Live scenario: Login redirects to ?next=. How do you demonstrate risk to a non-security PM?
Why it matters: Credential phishing, OAuth token theft.
STAR
Behavioral
Disagreement on severity
Q. Tell me about a time you disagreed with an engineer on risk severity.
A. STAR — stay respectful, data-driven.
STAR answer
S — Situation — Engineer rated an IDOR as low because IDs were UUIDs.
T — Task — Align on real user impact without escalating personally.
A — Action — Reproduced cross-user invoice download, showed PII fields, mapped to policy/compliance exposure, offered a one-line authZ guard as a patch sketch.
R — Result — Severity raised, fix scheduled same sprint, relationship stayed collaborative.
How to test / practice
- How to prepare: keep a severity rubric (confidentiality, integrity, blast radius).
- Bring a PoC video under 60 seconds.
- Propose the fix shape, not only the problem.
Pro tip: Never say “you’re wrong.” Say “here’s the user impact I can show.”
Live scenario: They still refuse. What do you escalate, and to whom?
Why it matters: Influence without ego — AppSec soft skill #1.
Clickjack
Client-side
Clickjacking
Q. How do you test and explain clickjacking quickly?
A. Clickjacking tricks users into clicking a hidden UI inside an attacker iframe. Test framing headers and CSP frame-ancestors; demonstrate with a lab iframe overlay.
How to test / practice
- Check X-Frame-Options and CSP frame-ancestors.
- Attempt framing sensitive actions (change email, confirm pay).
- Fix: deny/sameorigin framing or strict frame-ancestors; UX confirmations for critical actions.
Pro tip: Mention defense-in-depth: headers + re-auth for money moves.
Live scenario: App sets X-Frame-Options: SAMEORIGIN but embeds a partner iframe. What do you verify?
Why it matters: Forced actions while user thinks they clicked something else.
Traversal
Server-side
Directory traversal
Q. How do you approach path traversal in file download features?
A. Traversal uses ../ or encodings to escape the intended directory and read sensitive files. Validate canonical paths on the server after resolving user input.
How to test / practice
- Identify download/view endpoints with filename parameters.
- In labs, try ../ sequences and encodings; watch for normalization bypasses.
- Confirm whether the app joins paths unsafely.
- Fix: resolve to absolute path, ensure it stays under an allowlisted root; ignore user path separators.
Pro tip: Say “I canonicalize then prefix-check” — concrete and senior.
Live scenario: download?file=report.pdf. Outline your first five payloads in a lab.
Why it matters: Source code / secrets / config disclosure.
