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.
Deserial
Server-side
Insecure deserialization
Q. How do you find and explain insecure deserialization in an interview?
A. Untrusted serialized objects are rebuilt by the app — if class logic runs on load, attackers can trigger gadget chains for RCE or auth bypass. It sounds scary but often starts with spotting Java/.NET/PHP serialized blobs in cookies, params, or APIs.
How to test / practice
- Hunt serialized data: base64 blobs, rO0 (Java), O: (PHP), TypeName markers (.NET).
- Identify libraries on the stack (Commons Collections, etc.) in labs or SBOM.
- Use known gadget chains in authorized environments only; prove impact safely.
- Fix: avoid deserializing user input; integrity checks (HMAC); allowlists; signed tokens instead.
Pro tip: PortSwigger has ~10 labs on this topic — finish them and you can walk an interviewer through one chain calmly.
Live scenario: Session cookie decodes to a Java object. What is your first safe lab step before claiming RCE?
Why it matters: Remote code execution, privilege escalation, full server compromise.
LLM
Server-side
Web LLM attacks
Q. What web risks appear when an app embeds an LLM chat or agent?
A. LLM features introduce prompt injection, insecure output handling, excessive agency, and data leakage. Test like any API: who can trigger the model, what tools it can call, and whether user text can override system instructions.
How to test / practice
- Map inputs: chat UI, API, email-to-bot, plugins, RAG document stores.
- Try direct and indirect prompt injection; see if secrets or instructions leak.
- Check if the model can call tools (SQL, shell, HTTP) without human approval.
- Fix: strict tool allowlists, output encoding, separate privilege context, logging.
Pro tip: Newer PortSwigger LLM labs (~7) are great interview prep — cite one concrete injection you reproduced.
Live scenario: Support bot can “look up orders.” How could a user phrase a prompt to pull another customer’s data?
Why it matters: Data exfiltration, unauthorized actions via agent tools, reputational harm.
GraphQL
Server-side
GraphQL API vulnerabilities
Q. How do you test GraphQL differently from REST?
A. GraphQL exposes a schema and often a single endpoint. Bugs hide in introspection, batching/alias abuse, depth/complexity DoS, and authZ on resolvers — not only on URLs.
How to test / practice
- Run introspection (if enabled) or use saved schema from docs.
- Test nested queries for DoS; batch mutations for rate-limit bypass in labs.
- Swap object IDs in mutations; test field-level authZ (can user A read user B fields?).
- Fix: disable introspection in prod, query cost limits, resolver-level authZ.
Pro tip: PortSwigger GraphQL topic (~5 labs) — mention alias-based brute force as a realistic finding class.
Live scenario: /graphql accepts batched queries. How might that bypass login lockout in theory?
Why it matters: Mass data scrape, auth bypass on mutations, service degradation.
SSTI
Server-side
Server-side template injection
Q. How do you detect SSTI and explain impact?
A. User input is embedded in a server template engine (Jinja2, Twig, Freemarker, etc.). If evaluated, it becomes code execution on the server — often mistaken for XSS at first.
How to test / practice
- Probe with math payloads like {{7*7}} or ${7*7} in every reflective field.
- Identify engine from error messages or response differences.
- Escalate only in labs to prove RCE path; document template context.
- Fix: never pass user input into templates; strict sandbox; logic-less templates.
Pro tip: ~7 PortSwigger SSTI labs teach engine fingerprinting — reuse that flow in interviews.
Live scenario: Email preview renders “Hello {{name}}”. What harmless probe confirms SSTI vs simple substitution?
Why it matters: Server-side RCE, file read, lateral movement from web tier.
Cache
Server-side
Web cache poisoning
Q. What is web cache poisoning and where do you look?
A. You trick a shared cache into storing a malicious response keyed off an unkeyed input (header, cookie, param). Victims then receive poisoned content from the cache edge.
How to test / practice
- Identify caches (CDN, reverse proxy) and cacheable GET responses.
- Find unkeyed inputs: X-Forwarded-Host, X-Original-URL, fat GET params.
- Confirm with a unique cache buster param; observe hit on second request.
- Fix: cache only static assets; strict cache-key rules; validate Host headers.
Pro tip: PortSwigger cache poisoning (~13 labs) — great for showing methodical header fuzzing.
Live scenario: CDN caches /static/app.js. Which headers would you fuzz first and why?
Why it matters: Mass XSS, open redirect, or JS supply-chain via poisoned cached responses.
Host
Server-side
HTTP Host header attacks
Q. Why does the Host header still matter?
A. Apps and password-reset flows often build absolute URLs from Host or X-Forwarded-Host. Poisoning it can steal reset links, poison caches, or bypass access controls.
How to test / practice
- Send duplicate Host, X-Forwarded-Host, X-Host on password reset and webhooks.
- Observe whether emails or redirects use attacker-controlled hostnames.
- Test cache + virtual host routing confusion in authorized scope.
- Fix: allowlist Host values at proxy; hardcode canonical base URLs server-side.
Pro tip: ~7 Host-header labs on PortSwigger — classic consulting interview topic.
Live scenario: Password reset email contains a link built from the request Host. Describe the attack.
Why it matters: Account takeover via poisoned reset links, phishing on trusted domain.
Smuggle
Server-side
HTTP request smuggling
Q. Explain HTTP request smuggling in plain language.
A. Front-end and back-end disagree on where one HTTP request ends. Attackers smuggle a second request inside the first — leading to cache poisoning, auth bypass, or request hijacking.
How to test / practice
- Detect CL.TE or TE.CL desync using PortSwigger-style timing/differential probes in labs.
- Confirm with a smuggled request that hits an internal-only endpoint.
- Never test smuggling on production without explicit written approval.
- Fix: use HTTP/2 end-to-end, disable ambiguous transfer-encoding, normalize at proxy.
Pro tip: Deep topic (~22 labs) — in interviews, explain the concept + one lab PoC, not every variant.
Live scenario: CDN uses Content-Length; origin prefers chunked. What class of desync is that?
Why it matters: Bypass WAF/auth, steal other users responses, poison web cache.
OAuth
Server-side
OAuth authentication
Q. What OAuth misconfigurations do you hunt for?
A. OAuth delegates auth to an IdP — bugs are in redirect_uri validation, state/nonce, code reuse, and implicit flows leaking tokens in the fragment.
How to test / practice
- Map authorization + token endpoints; capture full redirect dance in Burp.
- Test redirect_uri open redirects, subdomain wildcards, path traversal tricks.
- Check state parameter, PKCE for public clients, token storage in browser.
- Fix: strict redirect allowlist, PKCE, short-lived codes, confidential client secrets.
Pro tip: ~6 OAuth labs — mention stealing codes via open redirect + pre-account takeover chain.
Live scenario: redirect_uri allows any subdomain of client.com. Why is that dangerous?
Why it matters: Account takeover, token theft, SSO bypass.
JWT
Server-side
JWT attacks
Q. How do you test JSON Web Tokens beyond “decode on jwt.io”?
A. JWTs are signed (or not) claims. Attacks: alg none/HS confusion, weak HMAC secrets, kid/jku header injection, and accepting expired tokens if validation is broken.
How to test / practice
- Inspect header/payload; note alg, kid, jku, x5u fields.
- Try alg=none, RS256→HS256 confusion with public key as secret in labs.
- Brute weak secrets only in authorized tests; check exp/aud/iss enforcement.
- Fix: allowlist algs, reject none, pin keys, short TTL + rotation.
Pro tip: ~8 JWT labs — walk through one header injection (kid) if asked for depth.
Live scenario: API accepts HS256 with secret "secret123". What is your interview-safe proof approach?
Why it matters: Authentication bypass, horizontal privilege escalation.
Proto
Client-side
Prototype pollution
Q. What is prototype pollution and where does it show up?
A. In JavaScript, merging untrusted JSON can alter Object.prototype — affecting all objects and sometimes leading to XSS, auth bypass, or RCE in Node backends.
How to test / practice
- Find merge/extend/deep-copy on user JSON (query params, API bodies).
- Probe __proto__, constructor.prototype keys in labs; watch for gadget behavior.
- Trace server-side Node if front-end pollution sinks into template/logic.
- Fix: freeze prototypes, use Map, schema validation, safe merge libraries.
Pro tip: Pair with PortSwigger client-side topics — pollution often chains into XSS or logic bugs.
Live scenario: Endpoint merges ?config={"isAdmin":true} style payloads. What key name do you try first?
Why it matters: XSS, bypass security flags, server-side gadget RCE in Node apps.
