25 Application Security Interview Questions and Answers

These 25 application security interview questions are for the person hiring: an AppSec lead, a product security manager or a Head of Security. They cover fundamentals, real scenarios from working with development teams, and short hands-on code review tasks, and each comes with what it tests and what a strong answer includes. A table further down groups them by focus, from code review to running a security programme.

AppSec sits between security and software engineering. A candidate needs to read unfamiliar code fluently, see how it could be abused, and persuade a developer to fix it. Generic cyber interviews miss the code, and generic coding interviews miss the security, so the questions below test the overlap. For questions that apply to every cyber role, see the main list of cyber security interview questions.

Application security interview questions on the fundamentals

Use two or three to check the foundations. Strong candidates answer with examples from code they have reviewed, not definitions from a list.

Question	What it tests	What a strong answer includes
1. Which OWASP Top 10 categories do you see most in real code?	Practical experience	Picks a few from the OWASP Top 10 and gives real examples, usually starting with broken access control, which tops the list. Does not recite all ten.
2. Give an example of an authentication flaw and an authorisation flaw.	Precision	Authentication: a weak password reset flow or predictable session tokens. Authorisation: a user changing an ID in a request to read someone else’s record, often called IDOR or broken object level authorisation.
3. How does SQL injection work, and how do you fix it properly?	The right fix	User input is treated as part of the query. The fix is parameterised queries. Knows ORMs can still be vulnerable through raw queries, and that input validation is a second layer, not the fix.
4. What is cross-site scripting, and why is input filtering not the fix?	Context-aware defences	Attacker-controlled script runs in another user’s browser, whether reflected, stored or DOM-based. The fix is encoding output for the context it lands in, framework auto-escaping and safe DOM APIs, with a Content Security Policy as an extra layer.
5. What is server-side request forgery, and why is it dangerous in the cloud?	Modern attack paths	The server fetches a URL the attacker controls, letting them reach internal services, including the cloud metadata service that hands out credentials. Fixes include allowlists of destinations, blocking internal address ranges and enforcing IMDSv2.
6. How should an application store passwords?	Getting cryptography right	A slow, salted password hashing algorithm such as Argon2id, bcrypt or scrypt. Not a fast hash like SHA-256 on its own, and never encryption.
7. What are SAST, DAST and SCA, and what does each miss?	Tooling realism	SAST scans source code but produces false positives and misses runtime issues. DAST tests the running application but only sees the paths it reaches. SCA finds known flaws in dependencies. None of them reliably finds business logic flaws.

Scenario-based application security interview questions

AppSec is as much about people as code. Listen for whether the candidate can prioritise, explain risk to developers, and make security fit how the teams actually ship.

Question	What it tests	What a strong answer includes
8. A developer says your finding is “not exploitable”. How do you handle it?	Influence without authority	Walks through the exploit path or builds a small proof of concept, agrees severity on evidence rather than opinion, and offers a practical fix. Uses the risk process if they still disagree, without making it personal.
9. You have one week to review a new payments feature. Where do you focus?	Prioritisation	Starts with a quick threat model of data flows and trust boundaries, then checks authorisation on every endpoint, how amounts and states are validated, race conditions, secrets, and logging.
10. A critical vulnerability is announced in a library used by 40 services. What do you do?	Supply chain response	Uses dependency inventories or SBOMs to find affected services and versions, checks whether the vulnerable code is actually reachable, prioritises internet-facing services, and uses a WAF rule as a stopgap where patching will take time.
11. How would you threat model a new API?	Structured design review	Draws the data flows and trust boundaries, walks through threats with a method such as STRIDE, writes abuse cases, and turns the results into tickets the team will actually work on.
12. A penetration test came back with 60 findings. How do you get them fixed?	Remediation at scale	Validates and deduplicates them, groups them by root cause, assigns owners, fixes patterns at the framework or library level where possible, sets deadlines by severity, and retests.
13. How would you add security checks to a CI/CD pipeline without slowing teams down?	Developer experience	Starts with high-confidence checks such as secret scanning and critical dependency flaws, tunes static analysis before it can block a build, and puts feedback in the pull request where developers already work.
14. A security researcher reports a vulnerability in production. What happens next?	Disclosure handling	Acknowledges quickly, reproduces it, assesses severity, fixes or mitigates, checks logs for signs it was already exploited, and keeps the researcher informed. Follows up with a root cause fix.
15. How do you decide whether a vulnerability is critical?	Risk judgement	Considers exploitability, impact, exposure, whether authentication is needed and how sensitive the data is. Uses CVSS as an input, not the answer.
16. A developer asks how to store an API key for a third-party service. What do you tell them?	Secrets management	In a secrets manager, never in code or in committed configuration, scoped to the minimum permissions, separate per environment and rotated.
17. How would you build a security champions programme?	Scaling AppSec	A volunteer in each team, training and protected time, champions as the first reviewer for their team’s changes, recognition, and a way to measure whether it is working.

Hands-on application security interview tasks

Short code review tasks to run in the interview, in a language the candidate will actually work with. Ten minutes of watching someone read code tells you more than any answer above.

Task	What it tests	What a strong answer includes
18. Review this pull request. What is wrong?	Code review	Finds the flaw, explains how it would be exploited, and proposes a fix that keeps the intended behaviour. See the example below.
19. Here is a login endpoint. Find the security issues.	Authentication review	Spots different error messages for unknown users and wrong passwords, which reveal which accounts exist, plus missing rate limiting and timing differences.
20. Here is a file upload handler. What could go wrong?	Input handling	Finds path traversal through the filename, no file type validation, files saved where the web server could execute them, and no size limit.
21. Here is a function that handles JWTs. Is it safe?	Token handling	Checks that the signature is verified with an expected algorithm, that expiry and audience are checked, and that the signing secret is not hardcoded.
22. Here is a dependency manifest. Which packages worry you?	Supply chain	Flags packages with known vulnerabilities, unpinned versions, abandoned projects and names that look like typosquats of popular packages.
23. Here is an API specification. Where would you attack first?	Attacker mindset	Endpoints that take object IDs, admin functions, fields that could allow mass assignment, and endpoints without rate limiting.
24. Here is a threat model for a new feature. What is missing?	Design review	Missing trust boundaries, data stores, third-party services or abuse cases, and threats with no mitigation.
25. Write this finding up for the developer who has to fix it.	Communication	Steps to reproduce, the impact in plain terms, the fix with example code, and a reference such as the OWASP ASVS. Respectful and specific.

Which questions for which kind of AppSec role?

Some AppSec roles are mostly code review. Others run a programme across dozens of teams. Pick from the areas the person will own.

Focus	What it covers	Questions to use
Secure code review	Finding and fixing flaws in code	3, 4, 6, 18, 19, 20, 21
Architecture and threat modelling	Design review before code is written	5, 9, 11, 23, 24
Pipeline and supply chain	Tooling, dependencies and secrets	7, 10, 13, 16, 22
Programme and people	Influence, prioritisation and process	1, 2, 8, 12, 14, 15, 17, 25

For security engineers who own infrastructure rather than code, see the security engineer interview questions.

What are the red flags in an application security interview?

• Cannot read code. Talks fluently about vulnerability classes but struggles to follow a 20-line function.
• Filtering as the fix for everything. Reaches for input sanitisation instead of parameterised queries, output encoding or proper authorisation checks.
• Scanner output as the answer. Treats tool findings as truth without checking whether they are exploitable.
• Security as a blocker. Talks about failing builds and saying no, with nothing about helping developers ship safely.
• No sense of business logic. Never considers flaws that tools cannot find, such as skipping a payment step or using a negative quantity.

Why a code review task beats any AppSec interview question

Every question above can be answered from reading. Finding the flaw in code you have never seen, under time pressure, cannot. Here is the kind of task that separates candidates in minutes. This Python endpoint returns an invoice to a signed-in user:

@app.route("/api/invoices/<int:invoice_id>")
@login_required
def get_invoice(invoice_id):
    invoice = Invoice.query.get_or_404(invoice_id)
    return jsonify(invoice.to_dict())

The user has to be signed in, so it looks protected. But nothing checks that the invoice belongs to them: change the number in the URL and you can read anyone’s invoice. A strong candidate spots it straight away, calls it broken object level authorisation, and fixes it by scoping the query to the current user:

invoice = Invoice.query.filter_by(id=invoice_id, owner_id=current_user.id).first_or_404()

A weak candidate looks for SQL injection, finds none, and says it is fine. That gap is invisible in a conversation and obvious in a task.

A full assessment takes the same idea further: a realistic service, several real flaws, and plausible decoys that a candidate who is guessing will pick.

portal.cyber-hire.com/challenge/code-review Code review

Used before the interview, a hands-on code review tells you who can read the diff, and the interview can focus on influence, prioritisation and design.

Frequently asked questions

What questions are asked in an application security interview?

Expect questions on common vulnerability classes such as injection, cross-site scripting and broken access control, the tools used to find them, and how to work with developers. Good interviews include reviewing real code, and sometimes threat modelling a design.

Do AppSec engineers need to be able to code?

They need to read code fluently in the languages your teams use, and write enough to build a proof of concept or a fix. They do not need to be the strongest developer in the room, but they must be able to follow unfamiliar code quickly.

What is the difference between application security and product security?

Application security focuses on finding and fixing flaws in software. Product security usually covers the whole product’s security, including design, infrastructure and incident response, and often owns the AppSec function within it.

How do you test an AppSec engineer before the interview?

Give them a realistic code change to review in a language you use, with a flaw that matters, and ask them to explain the exploit path and the fix. Score what they find and how clearly they explain it.

How CyberHire tests AppSec engineers before the interview

CyberHire is cyber technical screening that shows you who can read the diff before you book an interview. Pick the ready-made application security assessment or paste your job specification and generate one. Candidates review realistic code across languages, find the vulnerability, explain the exploit path and propose the fix, so you see how they read code, not just what they know.

Every candidate is scored the same way, with integrity signals next to each score. See how it works for application security hiring. If you would rather not build the assessment yourself, our team will build it with you.