Cybersecurity Interview Prep

Combine exploitability, business impact, exposure, affected data, existing controls, and evidence. CVSS is an input, not the final decision. Explain the likely attack path and remediation urgency.

Interview tip: Walk through one finding you ranked Critical versus Medium and what evidence changed the call.

Authentication establishes who the caller is. Authorization decides what that identity may do to a specific action or object. Test authorization on every server-side request, not only in the user interface.

Interview tip: Describe a bug where login worked correctly but object-level authorization failed.

Map assets and trust boundaries, review the schema, identify authentication and authorization decisions, test abuse cases and rate limits, inspect secrets and logging, then validate controls with negative tests.

Interview tip: Mention one concrete negative test, such as accessing another tenant's resource ID.

SAST finds source-level patterns early, DAST tests a running application from the outside, and SCA tracks vulnerable dependencies and licenses. They complement manual threat modeling and testing rather than replacing them.

Interview tip: Explain a false positive or miss you caught that scanners alone would not have handled.

Provide reproducible evidence, an actionable fix, a secure code example, clear ownership, and fast feedback in the existing workflow. Measure recurring root causes and improve paved-road components.

Interview tip: Share how you turned a repeated finding into a library, linter rule, or template.

It has a bounded scope, accurate data flows, assets and trust boundaries, realistic attacker goals, prioritized abuse cases, named controls, owners, and follow-up validation.

Interview tip: Name one abuse case you tracked from diagram to ticket to verification.

Start with trust boundaries and sensitive operations: auth decisions, crypto, file and network I/O, deserialization, and admin paths. Prefer tracing data from untrusted input to a sink over reading every line in order.

Interview tip: Pick one sink type (SQL, HTML, command, or redirect) and show how you traced it.

Encode or escape for the correct context on output, keep untrusted data out of dangerous sinks, use frameworks that escape by default, and add CSP as defense in depth. Client-side filters alone are not a control.

Interview tip: Contrast reflected, stored, and DOM XSS briefly with where each is fixed.

Use anti-CSRF tokens on state-changing requests, Prefer SameSite cookies as a supporting control, avoid cookie-only auth for APIs that expect Bearer tokens, and verify the server actually validates the token.

Interview tip: Call out the failure mode where a token is rendered but never checked.

Keep secrets out of repositories and images, inject them at runtime from a vault or managed secret store, rotate on exposure, scan history and pipelines, and give each service least-privilege credentials.

Interview tip: Describe how you would respond if a CI log printed a production token.

Issue unpredictable session identifiers, bind them to the authenticated identity, rotate on privilege change and login, set secure cookie attributes, expire idle and absolute sessions, and invalidate on logout and password reset.

Interview tip: Mention one concrete cookie flag set and why it matters.

Both. Validation constrains what enters the system. Encoding or parameterized APIs stop harmful interpretation at sinks. Relying on only one of them leaves gaps when data is reused in a new context.

Interview tip: Give an example where valid input was still dangerous when rendered or executed.

Inventory packages, monitor advisories, pin versions, review high-impact upgrades, remove unused libraries, and treat build and registry integrity as part of the threat model rather than a late patch scramble.

Interview tip: Talk about how you decide between upgrading, replacing, or accepting temporary risk.

Requirements and design get threat modeling, development gets secure patterns and review, CI gets automated checks, release gets verification, and operations gets monitoring and incident response. Late-only testing is expensive and incomplete.

Interview tip: Describe one control you moved earlier and what that changed for the team.

Accepting alg=none or unexpected algorithms, weak or shared secrets, missing audience and issuer checks, long-lived tokens without revocation strategy, and stuffing authorization claims the server never revalidates.

Interview tip: Explain one verification step you always insist on before trusting claims.

Log security-relevant events with enough context to investigate, redact secrets and personal data, avoid dumping full request bodies by default, protect log storage, and alert on auth failures, privilege changes, and unusual access patterns.

Interview tip: Name two fields you would never put in a production log line.

Confirm written authorization, scope, excluded systems, test windows, data-handling rules, emergency contacts, rate limits, evidence requirements, and stop conditions.

Interview tip: Mention one time unclear scope forced you to pause and get written clarification.

Create at least two users with different ownership and roles. Replay object requests while changing identifiers and methods. Test read, write, delete, export, and nested resources. The server must enforce ownership each time.

Interview tip: Include horizontal and vertical checks, not only swapping numeric IDs.

Use a controlled callback domain first, then permitted loopback or private targets. Record DNS and HTTP evidence, keep request volume low, and avoid cloud metadata unless scope explicitly permits it.

Interview tip: Explain how you prove impact without touching sensitive cloud credentials.

Stop risky exploitation, preserve minimal evidence, verify the result, notify the agreed emergency contact, explain immediate containment, and continue only after direction from the client.

Interview tip: Emphasize communication speed over continuing to chain exploits.

Reproduce manually, use a negative control, identify the exact security boundary that failed, capture request-response evidence, and distinguish theoretical exposure from demonstrated impact.

Interview tip: Describe a scanner finding you closed as noise and what confirmed it.

Verify the original path no longer works, test obvious bypasses and adjacent endpoints, confirm the root cause was fixed, check for regressions, and record the build or environment tested.

Interview tip: Say why retesting only the exact PoC URL is not enough.

Recon and mapping, authentication and session review, authorization across roles, input handling, business logic, misconfigurations, and evidence-backed reporting. Tools accelerate coverage, but hypotheses and manual validation drive quality.

Interview tip: Order your steps the way you actually work on a live engagement.

Start with low-impact probes, confirm interpretation with boolean or timing differences where allowed, prefer read-only proof, avoid destructive payloads, and capture the exact parameter and sink. Parameterized queries are the remediation story.

Interview tip: State how you would prove it without dumping an entire database.

Check account enumeration, brute-force protections, token entropy and reuse, host-header and open-redirect influence on reset links, MFA bypass paths, and whether old sessions die after credential change.

Interview tip: Highlight one reset-token flaw class and the evidence you would collect.

Content-type and extension mismatches, path traversal in stored names, executable locations, image parser issues, malware scanning gaps, and whether uploaded content can be rendered or executed in another user's context.

Interview tip: Separate storage abuse from content that becomes XSS or RCE.

Inspect the schema if available, probe authorization on every field and mutation, watch for batching and alias abuse, test nested query depth and cost, and verify that hiding the UI does not mean the server enforces access.

Interview tip: Give one example of a field-level authorization miss.

Base it on realistic attacker access, affected data, ease of exploitation, blast radius, and business context. Separate demonstrated impact from speculative chains, and keep the rating language consistent across findings.

Interview tip: Explain a finding you almost over-rated until you checked prerequisites.

Map roles and capabilities, attempt vertical jumps into admin functions, try horizontal access to peer data, abuse mass assignment and hidden parameters, and verify every privileged action server-side.

Interview tip: Mention testing both UI-hidden buttons and direct API calls.

When concurrent requests break an invariant such as balance, coupon use, seat booking, or one-time token consumption. Capture parallel requests, show the inconsistent state, and keep the proof small and reversible.

Interview tip: Describe how you would demonstrate it with two near-simultaneous requests.

State what was in scope, what was blocked by access or time, which environments were tested, and which attacker models were assumed. Clear limitations protect both the client and the quality of the conclusions.

Interview tip: Avoid implying full coverage when you only reached part of the attack surface.

A clear title, affected asset, prerequisites, exact steps, request-response evidence, demonstrated impact, remediation advice, and a severity rationale aligned with the program policy.

Interview tip: Keep the write-up short enough that a tired triager can reproduce in minutes.

Read the policy, build an asset inventory, understand core workflows and roles, map parameters and APIs, identify high-value state transitions, and test hypotheses rather than running noisy tools blindly.

Interview tip: Explain how policy reading changed where you spent your first hours.

Show the broken invariant in the smallest safe proof: bypassing a limit, changing ownership, receiving an unauthorized benefit, or reaching an impossible state. Do not create avoidable financial or user harm.

Interview tip: Prefer a reversible proof over a dramatic one.

Focus on new features and edge-case workflows, build target-specific notes, connect small observations into an attack path, and validate quickly before spending time on a polished report.

Interview tip: Talk about hunting where automation and copy-paste reports rarely look.

Stop when impact is proven, further action could affect real users or data, the program forbids the technique, or the next step crosses a trust boundary not in scope.

Interview tip: Hiring managers listen for judgment, not how far you could have pushed.

Stay factual. Restate the violated security guarantee, provide a minimal reproducible test and negative control, map impact to program policy, and ask one precise question about the disputed assumption.

Interview tip: Avoid arguing tone. Argue the security boundary with evidence.

Convert assets, endpoints, roles, and unusual parameters into questions: who should access this, what state can change, and what happens if I replay, reorder, or escalate? Recon without hypotheses is just collection.

Interview tip: Give one example of a parameter that became a specific test case.

Usually only when you can escalate it into another user's session, combine it with a second bug, or show a realistic delivery path allowed by the program. Alone, it rarely meets impact bars.

Interview tip: Show you understand program scope and impact, not just payload firing.

Focus on password reset, OAuth and SSO callbacks, email or phone change flows, session fixation, token leakage in logs and referrers, and IDOR on account settings. Prove control of the victim account with minimal persistence.

Interview tip: Name the flow you would test first on a consumer web app and why.

Check redirect URI validation, state and nonce handling, token leakage via referrer or postMessage, mix-ups between clients, and whether the resource server verifies audience. Small callback mistakes often become full takeovers.

Interview tip: Mention one redirect or state failure mode without dumping a generic checklist.

Map the finding to the program's severity guidelines, required privileges, affected users, and realistic attacker steps. Do not inflate with unrealistic chains. Do not undersell clear confidentiality or integrity breaks.

Interview tip: Reference how you would rewrite a report after reading the program's VRT or policy.

Prefer programs with clear scope and responsive triage, rotate targets when stuck, keep notes so you can resume fast, and invest deeper only when the attack surface or payout model justifies the hours.

Interview tip: Share a rule you use for quitting a low-signal target.

Use a callback you control, keep payloads uniquely tagged per sink, wait for hits from admin or support contexts, and report with the originating injection point plus the execution context when it fires.

Interview tip: Explain why unique callbacks matter for proving which sink caused the hit.

Each step should be necessary, reproducible, and inside policy. Show how lower-severity issues combine into a stronger outcome, and label assumptions clearly so triage can accept or reject the chain fairly.

Interview tip: Separate the chain story from the single most reliable standalone bug.

Stay within program rules, keep request volume low, prefer logical bypasses over traffic floods, and never turn a proof into service disruption. Many programs exclude or tightly restrict availability testing.

Interview tip: Show restraint: impact proof with a handful of requests beats a noisy blast.