Product Security Interview Questions (and What Good Answers Cover)

What a product security interview loop looks like

Most product security interview processes test the same three things: technical depth, security judgement and the ability to influence engineers. The exact format varies, but a typical loop for a mid-level or senior role looks like this.

Web and API security fundamentals

Expect these early. Interviewers are less interested in textbook definitions than in whether you understand why a vulnerability happens and how to prevent the whole class. A strong answer explains the root cause, gives a realistic example, and describes a systemic fix rather than a one-off patch.

• Explain the difference between authentication and authorisation. Where do authorisation bugs usually hide in a modern API? Good answers mention object-level checks (IDOR / BOLA), missing checks on less-used endpoints, and centralising authorisation logic.
• How does cross-site scripting work, and how would you eliminate it across a large codebase? Cover context-aware output encoding, frameworks that escape by default, dangerous sinks, and Content Security Policy as defence in depth.
• What is server-side request forgery, and why is it so dangerous in cloud environments? Mention access to instance metadata services, internal services, allow-listing, and network-level egress controls.
• How does SQL injection happen, and why do parameterised queries prevent it? Then: where can injection still happen with an ORM?
• Walk me through what happens during an OAuth 2.0 authorisation code flow. What goes wrong when PKCE or state validation is missing?
• What is CSRF, and why is it less common than it used to be? Discuss SameSite cookies, token-based protection and when they are still needed.
• How would you store passwords, and why? Look for slow, salted hashing such as Argon2, bcrypt or scrypt, and why fast hashes are unsuitable.
• What are the risks of insecure deserialisation, and how would you find it in code?

Secure code review

Almost every product security loop includes reading code. You will usually get a short snippet or pull request in a common language and be asked to find and explain the problems. Talk through your reasoning out loud. Interviewers want to see how you prioritise, not just whether you spot every issue.

• Here is an endpoint that updates a user's profile. What is wrong with it? A classic: the user ID comes from the request body rather than the authenticated session.
• This function builds a file path from user input. What could an attacker do? Path traversal, and how to canonicalise and validate paths safely.
• This code verifies a JSON Web Token. Is it safe? Look for algorithm confusion, missing signature verification, accepting 'none', and missing expiry or audience checks.
• This service fetches a URL provided by the user. What would you change? SSRF, redirects, DNS rebinding, and allow-lists.
• Which of the issues you found would you fix first, and why? Prioritise by exploitability and impact, not by the order you found them.
• How would you stop this class of bug from appearing again? Secure-by-default libraries, a lint or static analysis rule, and tests.

Threat modelling and secure design

Design exercises separate strong product security candidates from good penetration testers. You will be given a system, often a simplified version of the company's own product, and asked to find the risks. There is no single right answer. Interviewers look for a structured approach, sensible prioritisation and practical mitigations.

A reliable structure: clarify what the system does and what it protects; draw the components, data flows and trust boundaries; walk each boundary looking for threats, using STRIDE or a similar prompt list; rank the threats by likelihood and impact; and propose mitigations that fit the team's constraints. Say which threats you would accept, and why.

• Threat model a file-sharing feature that lets users share documents via a public link.
• Design the authentication for a mobile app that talks to a public API. How do you handle tokens, refresh and device loss?
• A team wants to let customers upload and run custom scripts in our platform. What are the risks and how would you contain them?
• How would you secure service-to-service communication in a microservices architecture?
• We are adding a large language model feature that can read a customer's data and take actions. What are the new risks? Cover prompt injection, data exfiltration through tool use, authorisation of agent actions, and logging.
• Review the design of a webhook system. What could go wrong for us, and for our customers?

Cloud and infrastructure security

Because so many product vulnerabilities now sit in cloud configuration and deployment pipelines, most product security roles include infrastructure questions. You do not need to be a cloud specialist, but you should understand identity, secrets and the build pipeline.

• How do IAM roles and policies work in AWS, GCP or Azure? How would you find over-privileged roles at scale?
• Where should secrets live, and how would you detect secrets committed to source control?
• How would you secure a CI/CD pipeline? Cover who can change pipeline definitions, protected branches, short-lived credentials, and build provenance.
• What is a software supply chain attack? Give an example and explain how SBOMs, dependency pinning and signed artefacts help.
• How would you isolate workloads for different customers in a multi-tenant SaaS product?
• What are the security implications of a container running as root, or with the Docker socket mounted?

Vulnerability management and incident response

Product security teams usually own the process for handling vulnerabilities in the product, including those reported by external researchers. These questions test judgement under pressure.

• A researcher reports a critical vulnerability through our bug bounty programme on a Friday evening. Walk me through the next 48 hours.
• How do you decide the severity of a vulnerability? Discuss CVSS, and why context such as exploitability and exposure matters more than the score.
• A scanner reports 4,000 findings across our services. How do you decide what to fix?
• When should a company publish a security advisory or request a CVE for its own product?
• After an incident, what makes a good root-cause analysis?

Behavioural and influence questions

These carry more weight than many candidates expect. Product security engineers rarely have the authority to force a fix, so interviewers want evidence that you can persuade, prioritise and keep good relationships with engineering teams. Use specific examples with a clear situation, what you did, and the outcome.

• Tell me about a time an engineering team disagreed with your security recommendation. What happened?
• Describe a security improvement you drove that removed a whole class of vulnerability.
• Tell me about a time you accepted a security risk rather than blocking a release. How did you decide?
• How do you explain a technical vulnerability to a product manager or executive?
• What is a security tool or process you introduced that engineers actually liked using?
• Tell me about a mistake you made in a security assessment and what you learned.

Coding and automation tasks

Many companies include a practical task, particularly for roles that build security tooling. Common examples are parsing logs to find suspicious activity, writing a script that checks repositories for a misconfiguration, writing a static analysis rule for a vulnerability pattern, or fixing a vulnerable function and adding a test. Readable, well-tested code beats clever code. Explain your trade-offs as you go.

How to prepare

Preparation that works: practise explaining vulnerability classes out loud; review real code, for example past CVE fixes in open-source projects; do two or three timed threat modelling exercises on systems you know; and prepare five or six stories from your own experience that show influence, prioritisation and learning from mistakes.

Research the company's product before the interview. If you can talk intelligently about its likely threat model, its public security writing, or recent advisories, you will stand out. Check the likely pay band in our product security salary guide before the offer stage.

Questions to ask your interviewers

Interviews run both ways. These questions reveal a great deal about whether a product security team is set up to succeed.

• How early is product security involved in design decisions?
• Who owns fixing vulnerabilities: the security team or the engineering teams?
• What does the team's work split look like between reviews, tooling and incident response?
• What was the last significant security improvement the team shipped?
• How is success measured for this role after six months?
• What does the career path to staff or principal look like here?

Find your next role

When you are ready, browse all current product security jobs or application security roles. If you are still planning a move, start with how to get into product security.

Frequently asked questions

What questions are asked in a product security interview?

Expect web and API security fundamentals (authorisation, XSS, SSRF, injection, OAuth), a secure code review exercise, a threat modelling or design exercise, cloud and CI/CD security questions, vulnerability handling scenarios, and behavioural questions about influencing engineering teams.

How do I prepare for a threat modelling interview?

Practise a consistent structure: clarify the system, draw components and trust boundaries, walk each boundary for threats using a prompt list such as STRIDE, prioritise by likelihood and impact, and propose practical mitigations. Do a few timed practice runs on systems you know.

Is there a coding interview for product security roles?

Often, yes. It is usually practical rather than algorithmic: writing a script to analyse logs or repositories, writing a static analysis rule, or fixing a vulnerable function and adding a test.

How are product security interviews different from penetration testing interviews?

Product security interviews put more weight on secure design, systemic fixes, code review and influencing engineers. Penetration testing interviews focus more on finding and exploiting vulnerabilities in a given system.