--- title: Application Security Engineer Interview Questions (2026) description: Application security engineer interview questions and answers — OWASP Top 10, threat modelling, secure code review, secrets, SDLC integration and incident response. url: https://usegreenroom.app/blog/application-security-engineer-interview-questions last_updated: 2026-08-01 --- ← Back to blog Technical · Security # Application security interview questions: findings that get fixed August 1, 2026 · 13 min read ![Application security engineer interview questions and answers — guide cover from Greenroom, the AI mock interviewer](/assets/blog/application-security-engineer-interview-questions-hero.webp) He found the vulnerability, wrote it up properly, assigned it a CVSS score of 8.1 and filed the ticket. Four months later it was still open, because the team that owned it had a roadmap, no security context, and a ticket from someone they had never met explaining that their code was wrong. The finding was correct. The outcome was zero. That gap is what **application security engineer interview questions** are really testing. Vulnerability knowledge is necessary and it is also the easy half — you can study OWASP. The harder half is threat modelling a feature you have just been told about, reviewing code you did not write, and getting engineers who do not report to you to change something. This guide covers both. ## Vulnerability classes, at mechanism level Knowing the names is table stakes. Interviewers probe the mechanism and the correct fix. - **SQL injection.** The fix is parameterised queries — not escaping, not a WAF, and not input validation alone. Be able to say why: parameterisation separates code from data at the driver level, so the input can never be parsed as SQL. Also know second-order injection, where the payload is stored and executed later. - **XSS.** Stored, reflected and DOM-based, and the fix differs by context: output encoding appropriate to where the value lands (HTML body, attribute, JavaScript, URL), plus a Content Security Policy as defence in depth. Know why `innerHTML` and `dangerouslySetInnerHTML` are the usual culprits. - **SSRF.** The one that matters most in cloud environments, because it reaches internal metadata endpoints. The fix is an allowlist of destinations plus network segmentation, not a blocklist — and know why blocklists fail against redirects and DNS rebinding. - **IDOR and broken access control.** Consistently the highest-impact real-world class. The fix is authorisation checked server-side on every object access, not obscured identifiers. - **Insecure deserialisation**, and why accepting serialised objects from users is dangerous by design. - **CSRF**, and why `SameSite` cookies plus a token, and why a JSON API with a custom header is less exposed. - **Path traversal, SSTI, XXE**, and the safe defaults for each. - **Supply chain.** Dependency confusion, typosquatting, and compromised packages. Increasingly the most-asked area, and worth naming SBOM and artifact signing. Our [API security interview questions](/blog/api-security-interview-questions) guide covers the service layer. ## Threat modelling Expect a live exercise: "we are building a feature that lets users upload a profile photo — threat model it." Structure that works: - **What are we building?** Data flow: who sends what, where it is stored, who reads it, what trust boundaries it crosses. - **What can go wrong?** Use STRIDE as a checklist — spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege — rather than free-associating. - **For the upload example specifically:** file type validation done server-side by content rather than extension, size limits to prevent denial of service, stripping EXIF data which contains location, storing outside the web root or in object storage with no execute permission, serving from a separate origin so a stored HTML file cannot run in your domain, virus scanning, and authorisation on retrieval so users cannot enumerate other people's photos. - **What are we going to do about it?** Prioritise by realistic impact and likelihood, not by CVSS alone. - **Did we do a good job?** How you would verify — a test, a scan, a check in CI. The single strongest habit here is asking about trust boundaries before listing threats. ## Secure code review You will be shown a snippet and asked what is wrong. Practise reading for: - Concatenated queries or commands. - User input reaching a template, a filesystem path, a URL fetch, or a deserialiser. - Authorisation checks missing on an object lookup — the IDOR pattern, and the most commonly planted bug. - Comparisons of secrets with `==` rather than a constant-time comparison. - Randomness from a non-cryptographic source for a token. - Errors that leak stack traces or internal identifiers to the user. ```code:py # what is wrong here? three things, and the ordering of your answer matters @app.route('/invoice/') def get_invoice(invoice_id): q = f"SELECT * FROM invoices WHERE id = {invoice_id}" # 1. SQL injection row = db.execute(q).fetchone() # 2. no authorisation check: return render_template_string(row['notes']) # any user reads any invoice # 3. SSTI: user content as template ``` Say the impact ordering out loud: "the injection is the most severe, but the missing authorisation check is the one most likely to already be exploited, because it needs no skill at all." That prioritisation is what a senior AppSec answer sounds like. ## Authentication, sessions and secrets - **OAuth and OIDC** — the authorisation code flow with PKCE as the modern default, why the implicit flow was deprecated, and the difference between authentication and authorisation. Our [OAuth interview questions](/blog/oauth-interview-questions) guide covers the flows. - **JWTs** — the `alg: none` and algorithm confusion attacks, why revocation is genuinely hard, why short expiry plus refresh is the standard answer, and why storing a token in `localStorage` exposes it to XSS. Our [JWT interview questions](/blog/jwt-interview-questions) guide covers this. - **Sessions and cookies** — `HttpOnly`, `Secure`, `SameSite`, and rotation after privilege change. - **Password storage** — a memory-hard algorithm such as Argon2 or bcrypt with a proper work factor, never a fast hash, and per-user salting handled by the algorithm. - **Secrets management** — never in the repository, short-lived credentials over static keys, OIDC federation between CI and cloud, and rotation. Our [CI/CD interview questions](/blog/ci-cd-pipeline-interview-questions) guide covers the pipeline side. ## Integrating security into the SDLC This is where the round is won, because it is where the job actually is. - **Tooling and its limits.** SAST catches patterns and produces false positives; DAST tests the running application and misses what it cannot reach; SCA finds vulnerable dependencies and is often the highest-value tool per rupee. Know what each cannot do. - **What blocks a build versus what files a ticket.** Blocking on every medium finding trains developers to bypass you. A tight blocking policy on critical issues plus a triaged backlog is credible. - **Reachability matters.** A critical CVE in a dependency you never call is not a critical risk. Saying this shows you understand why security teams lose credibility. - **Secure defaults over developer education.** A framework that escapes output by default prevents more XSS than any training programme. Prefer paved-road solutions. - **Security champions.** An engineer embedded in each team who has context and can be reached — the standard answer to how you scale a small security team. - **Threat modelling at design time**, because a design flaw found in code review is expensive and one found in production is worse. ## Incident response and influence Expect a scenario: "a researcher reports an exposed endpoint returning other users' data. What do you do?" Answer in order — verify and reproduce, assess scope and severity, contain by disabling or restricting the endpoint, preserve logs, determine whether it was exploited and for how long, notify legal and privacy for any regulatory obligation such as India's DPDP requirements, fix, then run a blameless post-incident review with a structural change. The influence question is equally likely: "a team refuses to fix a finding." The good answer is to understand their constraints, re-express the risk in terms they care about — customer data, a specific realistic attack, an audit obligation — offer to help with the fix rather than only reporting it, and escalate with a recommendation rather than a complaint. Reporting a finding is not the job; getting it fixed is. **The core truth:** AppSec interviews are half vulnerability knowledge and half organisational skill. Candidates who can only do the first half describe findings; the ones who get hired describe outcomes. ## Where each prep option actually helps - **The OWASP Top 10 and the OWASP Cheat Sheet Series** — the cheat sheets in particular are the practical version, and they are what interviewers quietly base questions on. - **PortSwigger Web Security Academy** — free, hands-on, and the fastest way to actually understand SSRF and access control rather than recite them. - **Threat model something you built** — one real exercise makes the live version far easier. - **A CTF or a bug bounty programme** — even a small amount of real exploitation changes how you talk about impact. - **ChatGPT** — good for generating vulnerable code snippets to practise reviewing. It will not tell you your finding was ignored for four months, which is the part the job is about. - **Greenroom** — the spoken layer. [Ari, the AI interviewer](/) runs threat modelling and incident scenarios out loud, which is exactly how they happen. Honest tradeoff: Ari will not scan your codebase, so use the hands-on labs too. Our [cybersecurity analyst interview questions](/blog/cybersecurity-analyst-interview-questions) guide covers the detection and response role, which is adjacent but distinctly different. ## Frequently asked questions ### What questions are asked in an application security engineer interview? Six areas recur: vulnerability classes at mechanism level rather than by name, a live threat modelling exercise on a feature described in the room, secure code review of a snippet, authentication and secrets covering OAuth, JWTs, sessions and key management, integrating security into the SDLC including what blocks a build versus what files a ticket, and an incident response scenario. The second half — threat modelling and SDLC integration — is where most candidates are separated. ### How do you threat model a feature in an interview? Work through four questions in order. What are we building, expressed as a data flow with trust boundaries; what can go wrong, using STRIDE as a checklist rather than free-associating; what are we going to do about it, prioritised by realistic impact and likelihood rather than CVSS alone; and did we do a good job, meaning how you would verify with a test or a check in CI. Asking about trust boundaries before listing threats is the single strongest habit to demonstrate. ### What is the correct fix for SQL injection? Parameterised queries, because parameterisation separates code from data at the driver level so user input can never be parsed as SQL. Escaping, input validation and a web application firewall are all weaker answers — useful as defence in depth but not as the primary control. It is also worth mentioning second-order injection, where a payload is stored safely and then executed later when it is concatenated into a query elsewhere. ### What is the difference between SAST, DAST and SCA? SAST analyses source code for vulnerable patterns and produces significant false positives. DAST tests the running application from the outside and misses anything it cannot reach or authenticate into. SCA scans dependencies for known vulnerabilities and is frequently the highest value per unit of effort. A strong answer also covers what each cannot do, and notes that reachability matters — a critical CVE in a dependency your code never calls is not a critical risk. ### How do you get engineering teams to fix security findings? Understand their constraints first, then re-express the risk in terms they care about — specific customer data, a realistic attack path, or an audit obligation — rather than restating a CVSS score. Offer to help with the fix instead of only reporting it, and escalate with a recommended action rather than a complaint. Also invest in structural approaches: secure defaults and paved-road frameworks prevent more issues than training, and security champions embedded in teams scale a small security function. ### What should you do when a security incident is reported? Verify and reproduce it first, assess scope and severity, contain by disabling or restricting the affected path, and preserve logs before anything is changed. Then determine whether it was actually exploited and for how long, involve legal and privacy for any regulatory notification obligation such as India's DPDP requirements, deploy the fix, and run a blameless post-incident review whose output is a structural change rather than a reminder to be careful. Threat modelling and incident calls happen out loud, under time pressure, with people watching. [Greenroom](https://usegreenroom.app/) runs those scenarios with Ari. Free to start. Curious how it works? See [how AI mock interviews work](/blog/ai-mock-interview).