In this article
The lifecycle and the mindset
What does an application security engineer do?
An application security engineer helps developers design, build, test and release software with fewer vulnerabilities. Typical work is threat modelling designs, reviewing code, running scanners, triaging findings and fixing root causes. The National Institute of Standards and Technology (NIST) Secure Software Development Framework (SSDF) groups the practices into four: prepare the organisation, protect the software, produce well-secured software and respond to vulnerabilities (NIST SSDF project page, October 2026). The wider field is mapped in the cyber security interview questions guide.
Why it is asked: it shows whether you see the job as enabling developers, not blocking them.
What is the difference between a vulnerability, a threat and a risk?
A vulnerability is a weakness, such as a query built by string concatenation. A threat is something that could take advantage of it, such as an attacker scanning for injection points. Risk is the likelihood that the two meet multiplied by the damage if they do, so a flaw behind a login on a low-value feature may rank below a smaller flaw on a public payment page.
Why it is asked: it tests whether you can define the three terms precisely and keep them apart.
Where do you add security checks in the development lifecycle?
At every stage, not only at the end. In design, a threat model. In code, peer review and a static analysis tool whose findings a human reviews. In testing, dynamic testing and fuzzing for input handling. After release, regular automated analysis and a vulnerability disclosure policy. These match the code review, testing and vulnerability-response practices in NIST Special Publication 800-218 (February 2022).
Why it is asked: it tests whether you think in pipelines, not a final audit.
Text description of the diagram
- In design, a threat model; in code, peer review and a static analysis tool whose findings a human reviews.
- In testing, dynamic testing and fuzzing; after release, regular automated analysis and a vulnerability disclosure policy.
Threat modelling and design
What is a threat model, and how do you run one?
A threat model is a structured description of what you are building, what could go wrong and what you will do about it. The Open Worldwide Application Security Project (OWASP) threat modeling guide frames four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job. Run it on sign-in, access control and key flows, with the developers in the room.
Why it is asked: designing out a flaw is cheaper than patching it.
What is the STRIDE checklist?
Spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege (STRIDE) are a checklist of six threat types, each tied to a property it breaks: authentication, integrity, accounting, confidentiality, availability and authorisation. The OWASP guide pairs each with an example, such as using a stolen token to impersonate a user for spoofing. Walk each part of a diagram through the six types and write down the mitigations.
Why it is asked: it shows you have a repeatable method, not only intuition.
What is the difference between insecure design and insecure implementation?
Insecure design means the needed control was never created, while insecure implementation means a good design was coded with a defect. OWASP states that "a secure design can still have implementation defects" and that a flawless build cannot repair a flawed design (OWASP Top 10:2025, A06). Missing rate limits on a password-reset flow is a design gap; a missed check in one endpoint is an implementation bug.
Why it is asked: it decides whether the fix is a review or a redesign.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Injection and browser attacks
How do you prevent SQL injection?
Use prepared statements with variable binding in Structured Query Language (SQL) queries, which force the developer to define all the SQL code first and pass each parameter later, so the database can tell code from data. The OWASP SQL injection guide lists properly built stored procedures and allow-list input validation as further defences, and marks escaping user input as strongly discouraged.
Why it is asked: it is the standard test of whether you know the real fix, not input filtering.
What is cross-site scripting, and how do you prevent it?
Cross-site scripting (XSS) is an attack in which untrusted data is rendered as script in a victim's browser. The main defence is output encoding. Output encoding is a step that turns untrusted input into text the browser shows as data, chosen for the context: HTML body, attribute, JavaScript, CSS or URL. Use the framework's default escaping and safe sinks such as textContent; a content security policy is an extra layer, not the primary defence (OWASP XSS guide, read October 2026).
Why it is asked: context-aware encoding separates experienced answers from "sanitise input".
What is cross-site request forgery, and how do you prevent it?
Cross-site request forgery (CSRF) makes a logged-in user's browser send a state-changing request the user did not intend. Defend with a synchroniser token that the server checks on every such request, or a signed double-submit token for stateless apps, and never change state with a GET request. The SameSite cookie attribute helps but is not a full defence, and XSS can defeat every CSRF defence (OWASP CSRF guide, read October 2026).
Why it is asked: it checks whether you know both the fix and its limits.
What is server-side request forgery, and why does it matter in the cloud?
Server-side request forgery (SSRF) abuses an application to make requests to internal or external networks, or to the machine itself, on the attacker's behalf. In cloud environments it is often aimed at metadata services to steal credentials. Prefer an allow-list of known destinations, build requests yourself instead of accepting full URLs, and limit outbound traffic with network rules; OWASP also recommends moving to the second version of the Amazon Web Services (AWS) metadata service (OWASP SSRF guide, read October 2026).
Why it is asked: it tests cloud-aware thinking on a modern, high-impact flaw.
Text description of the diagram
- SQL injection is fixed with prepared statements and variable binding.
- Cross-site scripting is fixed with output encoding chosen for the context.
Access control, passwords and secrets
What is broken access control, and what is an insecure direct object reference?
Broken access control lets users act beyond their permissions. An insecure direct object reference (IDOR) is the common case: the app exposes an identifier and does not check that the caller owns the object, so changing the number returns another user's data. OWASP ranks broken access control first in 2025 and says every tested application had some form of it (A01, read October 2026). Deny by default and check ownership on every request.
Why it is asked: it tests whether you know the top-ranked web risk, which OWASP found in every tested application.
How should an application store passwords?
Hash them with a slow, ideally memory-hard, algorithm and a unique salt per user. The OWASP password storage guide prefers Argon2id with at least 19 MiB of memory, two iterations and one degree of parallelism, with scrypt, bcrypt (work factor at least 10, 72-byte limit) and PBKDF2 (password-based key derivation function 2, 600,000 or more iterations) as fallbacks. A salt makes identical passwords hash differently and forces attackers to crack each hash separately.
Why it is asked: it tests whether you know current parameters, not "a fast hash with a salt".
How do you handle session tokens and JSON Web Tokens?
Invalidate sessions on logout, keep stateless JavaScript Object Notation (JSON) Web Tokens (JWTs) short-lived, and use refresh tokens with revocation when access must last longer. That is the guidance in OWASP's access control category, which also recommends logging failures and rate-limiting application programming interfaces (APIs) (A01, read October 2026). A stateless token cannot be recalled before it expires, which is the trade-off to name.
Why it is asked: it probes the revocation problem many designs ignore.
How do you manage secrets such as API keys?
Keep secrets out of source code and configuration files, store them in one standard secrets manager, give each reader only the secrets it needs, and rotate them so stolen values stop working quickly. The OWASP secrets management guide names plaintext secrets hard-coded in code and configuration as the common failure, and says exposed keys should undergo immediate revocation, because restarting the application does not itself revoke stolen credentials.
Why it is asked: it tests whether you know where secrets belong and how to respond when one leaks.
The pipeline, tools and priorities
What is the difference between static analysis, dynamic testing and dependency scanning?
Static analysis is a tool that checks code for vulnerabilities without running it. Dynamic testing exercises the running software, including fuzz testing of input handling. Dependency scanning checks third-party components for publicly known vulnerabilities. NIST Special Publication 800-218 gives an example of each: a static analysis tool with a human reviewing its report, dynamic tests in the automated suite, and regular checks of acquired components (NIST, February 2022).
Why it is asked: it separates tool vocabulary from knowing what each one finds.
What is a software supply chain failure, and how do you reduce the risk?
It is a breakdown or compromise in building, distributing or updating software, often through third-party code or tools. OWASP's 2025 list names it as its own category. Mitigations include a software bill of materials, which is an inventory of every component in the software, tracking indirect dependencies, signed packages, deliberate upgrades, staged rollouts and hardened build systems (A03, read October 2026).
Why it is asked: dependency risk is now a standard interview topic.
How do you prioritise a backlog of vulnerabilities?
Combine severity with exposure and evidence of use: is the component reachable from the internet, what data does it guard, and is the flaw being exploited. The Cybersecurity and Infrastructure Security Agency (CISA) says organisations should use its Known Exploited Vulnerabilities catalog as an input to prioritisation (CISA, read October 2026). NIST asks for a risk-based response to each vulnerability, so a single score is not enough on its own.
Why it is asked: it tests judgement when there is more work than people.
What is the OWASP Top 10, and how would you use it?
The OWASP Top 10 is a ranked awareness list of the most critical web application risk categories. The 2025 edition runs from broken access control, security misconfiguration and software supply chain failures through to mishandling of exceptional conditions (OWASP Top 10:2025). Use it to frame training and findings, and use the Application Security Verification Standard (ASVS) version 5.0.0, published 30 May 2025, as the detailed checklist (OWASP).
Why it is asked: it shows you know a list is a starting point.
How is the CWE Top 25 different from the OWASP Top 10?
The Common Weakness Enumeration (CWE) Top 25 ranks specific weakness types by a danger score, frequency times severity, computed from 39,080 Common Vulnerabilities and Exposures (CVE) records published between 1 June 2024 and 1 June 2025. In 2025 the top four were cross-site scripting, SQL injection, cross-site request forgery and missing authorization (CWE Top 25 list, read October 2026 and methodology). OWASP groups risks by category and uses survey input as well as data.
Why it is asked: it tests whether you can tell a ranking of weakness types from a list of risk categories.
Process and judgement
How do you review code for security?
Start from trust boundaries: where input enters, where permission checks happen, where secrets and cryptography are used. Use a checklist, such as the ASVS, and let a static analysis tool find the routine issues so you spend time on logic. NIST suggests peer review, review checklists, and recording and triaging every finding in the team's issue tracker (NIST SSDF, code review practice, February 2022).
Why it is asked: it shows how you find flaws that tools miss.
How do you respond when someone reports a vulnerability in your product?
Acknowledge it, reproduce it, rate the risk and fix it by the plan that risk calls for. NIST's practices call for a vulnerability disclosure policy that is easy to find, a risk-based response for each issue, root-cause analysis over time and checks for similar flaws elsewhere. Add a regression test so the same bug cannot return (NIST SSDF, vulnerability response practices, February 2022).
Why it is asked: handling a report well matters as much as preventing one.
How do you persuade a team to fix a finding they disagree with?
Show the attack path in their own system, state the impact in terms they care about, and offer the smallest fix. Agree a date tied to risk, and escalate with evidence if it slips. Avoid blaming; ask what stops them. Keep a record of the agreed decision. Read about the situation, task, action, result (STAR) structure in the STAR method guide for how to tell this as a story.
Why it is asked: security work succeeds through influence, not authority.
Tell me about a time you found or prevented a security issue.
Pick a true, modest example and use the STAR structure. Name the weakness, how you found it, who you worked with and what changed, ideally with a measurable result such as a closed class of findings. Own your part and what you would do differently. See how to answer interview questions for structure.
Why it is asked: it checks real experience and honesty about scope.
How these interviews are run
Application security loops often mix a coding or code-review exercise, a design or threat-modelling discussion and behavioural questions, though formats vary by employer, so ask the recruiter. For the wider process see how interview loops work. Neighbouring topics are on the security operations center analyst questions, the threat intelligence questions and the AI agent security page.
Follow-up questions
Why did you choose application security?
Give a short, true story with three parts: what first drew you to it, one concrete thing you built, broke or fixed that confirmed it, and what you want to do next. Interviewers use this to hear whether you like helping developers fix root causes, so name a real example, such as a vulnerability you reported or a code review you learned from, rather than a general claim about wanting to protect users.
What are common application security interview questions?
The groups on this page are the usual ones: lifecycle and mindset, threat modelling, injection and browser attacks, access control and secrets, the build pipeline and judgement questions. Employers differ, so check the job post for its stack and ask the recruiter which rounds to expect.
How do I answer application security interview questions?
State the answer in one sentence, name the weakness and its fix, then give a short example from your own work. Use the situation, task, action, result (STAR) structure for behavioural questions, and say so plainly when you do not know something rather than guessing.
- Security belongs at every stage: threat model, review and analyse code, check dependencies, test, then monitor and respond.
- Fix the root cause: parameterised queries, context-aware output encoding, anti-forgery tokens, allow-listed destinations, ownership checks on every request.
- Hash passwords with Argon2id and a unique salt; keep secrets out of code and rotate them.
- Prioritise vulnerabilities by exposure and evidence of exploitation, not a score alone.
- Tell security stories with situation, task, action and result, and own your part.
Sources
- OWASP Top 10:2025 — OWASP Foundation (page shows no release date; read 2026-10-24), 24 Oct 2026
- OWASP Top 10:2025, A01 Broken Access Control — OWASP Foundation (read 2026-10-24), 24 Oct 2026
- OWASP Top 10:2025, A03 Software Supply Chain Failures — OWASP Foundation (read 2026-10-24), 24 Oct 2026
- OWASP Top 10:2025, A06 Insecure Design — OWASP Foundation (read 2026-10-24), 24 Oct 2026
- Secure Software Development Framework (SSDF) project page — NIST (page last updated 6 October 2026), 6 Oct 2026
- Secure Software Development Framework (SSDF) Version 1.1, NIST SP 800-218 — NIST, 3 Feb 2022
- OWASP prevention guide: SQL Injection Prevention — OWASP Foundation (read 2026-10-24), 24 Oct 2026
- OWASP prevention guide: Cross Site Scripting Prevention — OWASP Foundation (read 2026-10-24), 24 Oct 2026
- OWASP prevention guide: Cross-Site Request Forgery Prevention — OWASP Foundation (read 2026-10-24), 24 Oct 2026
- OWASP prevention guide: Server Side Request Forgery Prevention — OWASP Foundation (read 2026-10-24), 24 Oct 2026
- OWASP prevention guide: Password Storage — OWASP Foundation (read 2026-10-24), 24 Oct 2026
- OWASP prevention guide: Threat Modeling — OWASP Foundation (read 2026-10-24), 24 Oct 2026
- OWASP prevention guide: Secrets Management — OWASP Foundation (read 2026-10-24), 24 Oct 2026
- OWASP prevention guide: Authorization — OWASP Foundation (read 2026-10-24), 24 Oct 2026
- OWASP Application Security Verification Standard (ASVS) — OWASP Foundation (version 5.0.0, published 30 May 2025), 30 May 2025
- 2025 CWE Top 25 Most Dangerous Software Weaknesses and methodology — MITRE (page shows no date; read 2026-10-24), 24 Oct 2026
- 2025 CWE Top 25 methodology — MITRE (page shows no date; read 2026-10-24), 24 Oct 2026
- Known Exploited Vulnerabilities Catalog — CISA (page shows no date; read 2026-10-24), 24 Oct 2026
