Last updated: November 7, 2026
The best application security engineer interview questions in 2026 make a candidate find a real flaw in code and in a design, then explain how they got the developer to fix it. Reciting the OWASP list proves nothing, since every candidate has read it and most have it memorized in order.
A billing software company in Charlotte hired an application security engineer last year after a five-round loop that every finalist got through without much trouble. They were asked to explain cross-site scripting, to compare SAST with DAST, and to list what was in the OWASP Top 10, and the person they picked answered all of it cleanly and in sequence, like someone who had given the talk at a meetup before.
About four months later a customer’s own security team found a hole in the invoice service. Change the account number in a download URL like /invoices/48213/pdf to a neighboring number and you got back a different customer’s PDF, because the endpoint confirmed you were logged in and never confirmed the invoice was yours. The new hire had actually reviewed that service during his third week and called it fine, and to be fair it did look fine, with authenticated users only, input validated, and nothing a scanner would complain about.
Nobody had asked him to read an endpoint like that one during the loop, because they’d spent the loop asking him to describe things.
I’m the person on the intake call and I don’t read the code myself. Our security engineers run the technical screens, and I sit in on the debriefs with hiring managers, which is where most of what follows comes from. We earn a fee when you hire somebody our cybersecurity staffing team sends over, so weigh it accordingly, although the exercises below work fine without us.
Two nearby pages cover different ground. Scoping the req, what it pays, and whether you need the hire yet are in our guide to hiring an application security engineer, the wider loop for design, cloud, and incident response is in our security engineer interview questions, and the pipeline and secrets round sits in the DevSecOps engineer interview questions. This page covers only the AppSec round, the one where somebody has to read code, and if you’d rather have the whole search run for you, that’s what our application security engineer staffing team does every week. A third page, the posting that brings these candidates in, covers the job description side of the same search.
Why the Reading List Stopped Working
An application security engineer interview is a working session that tests whether a candidate can find flaws in code and design, rank them by real risk, and get them fixed by the developers who own them. Tool names and acronym recall are a warm-up at best.
The 2025 data gives you a better syllabus than a flashcard deck would. OWASP’s Top 10:2025 kept Broken Access Control at number one and reports that every application it tested showed some form of it, and the 2025 CWE Top 25 from MITRE, published in December, comes at the same problem from the CVE side. Cross-site scripting, SQL injection, and CSRF hold the top three spots, Missing Authorization climbed five places to fourth, and Authorization Bypass Through User-Controlled Key, which is the textbook object-ID bug, climbed six places to 24th.
That last entry is Charlotte. The code is valid in every way except for a question nobody wrote, and in my experience that’s exactly the kind of bug automated tools handle worst, since nothing in it is malformed enough to match a rule.
| What the data says | Where it comes from | What it earns in the loop |
|---|---|---|
| Broken Access Control stays at number one | OWASP Top 10:2025, A01 | A pull request with an authorization gap in it |
| Missing Authorization (CWE-862) up five places to fourth; CWE-639 up six to 24th | MITRE 2025 CWE Top 25 | The same gap, so a candidate can’t dodge it by naming a framework |
| Mishandling of Exceptional Conditions is new, with 24 mapped weaknesses including failing open | OWASP Top 10:2025, A10 | A catch block that quietly lets the request through |
| Insecure Design is its own category, because some flaws exist before any code does | OWASP Top 10:2025, A06 | A threat model on a feature that hasn’t been built |
Treat the table as a map and not a script. Pick the rows that match your product and leave the others alone.
Round One: Read a Pull Request With Three Problems In It
Give it forty-five minutes. Take a real pull request from your own repository, sanitize it, and keep (or plant) three genuine issues plus one decoy that looks bad and isn’t, and hand the candidate the description a developer would really write, which is typically two lines and a ticket number. Then ask the three questions below in order and say as little as you can manage.
Walk me through this endpoint.
It’s the invoice download from Charlotte, anonymized, and a Spring controller that calls invoiceRepository.findById(id) with whatever number arrived in the path. A strong candidate’s first move is a question back, who is calling this and which tenant are they in, and then they point out that being logged in and owning the record are two separate facts, which the code treats as one.
Listen for where they want the fix to live. Weaker candidates patch this one controller, whereas better ones push the ownership check down into the data-access layer, something like findByIdAndTenantId, so the next endpoint somebody writes on a Friday afternoon inherits it without anyone remembering to ask, and then they wonder aloud what else in the service takes an ID from the request and whether a Semgrep or CodeQL rule could catch the pattern. The shallow answer is “switch to UUIDs,” which makes the hole harder to stumble on but doesn’t close it, since anybody who legitimately holds one invoice ID can still request another customer’s.
How bad is this one?
This is the decoy, a SQL string built with concatenation for an ORDER BY clause where the column name comes from an enum two layers up. A scanner will flag it as injection, and honestly the pattern deserves a second look, but it’s also the standard way to do it because identifiers can’t be bound as query parameters, and nothing a user types ever reaches it.
Candidates who call that critical are showing you how they’ll behave around your developers, because engineers stop opening messages from the person who labels everything an emergency, and in my experience that happens somewhere around month four. What you want to hear is closer to “that’s fine as long as the enum is the only source, I’d confirm that and move on,” with a reason attached.
What happens when the service this code calls is down?
Somewhere in the diff there’s a call to an internal permissions service wrapped in a try block, and the catch logs a warning and returns a default role so the request carries on. It’s not mentioned in the description, and why would it be, since the developer who wrote it was thinking about the day the service is up.
OWASP added Mishandling of Exceptional Conditions to the Top 10 for 2025, covering 24 weaknesses, and failing open is the one that matters here. A senior candidate spots the catch block without a nudge, asks what the default role is allowed to do, and wants the default to be deny, and a good one will also ask what the error response tells the caller, since leaking internals in a failure message is a separate entry on that list. Someone who reads straight past it has reviewed the happy path only, which is also what most scanners do.
Round Two: Threat-Model Something That Doesn’t Exist Yet
There’s no code in this one. You hand over a single paragraph of feature request, in this case that customers can email a read-only link to a report so an outside contractor can view it without creating an account, and then you stay quiet for ten minutes, which is a perfectly legitimate thing for an interviewer to do.
The first thing worth watching is whether the candidate starts talking or starts asking. Who is the contractor, can the link be forwarded, does the report ever pull in another customer’s data, how long should the link last, and what does revoking mean when it’s already sitting in somebody’s inbox. Tokens in URLs also end up in proxy logs, browser history, and Referer headers once the report page loads a third-party script, and the candidates who’ve been burned by that tend to say so unprompted. Anyone who recites STRIDE and fills in the grid without asking a single question has learned the method and never used it, and OWASP’s name for what that round exposes is Insecure Design.
A few things I’d count as good signs:
- Forwarding comes up before you raise it.
- They rank the threats and then name one they’d leave alone for now, with a reason, because everybody can list risks and very few will say out loud which one they’re accepting.
- They turn what they said into something testable. The OWASP Application Security Verification Standard shipped version 5.0.0 in May 2025, and ASVS is a sensible place to pull requirements from, so a candidate who reaches for it instead of inventing a checklist on the spot has probably done this at a real company.
- A question for the product manager about whether the link could be scoped to one report and one email address instead of working as a bearer token for anyone who has it.
That last one is my favorite, because the candidate is making the feature safer by changing the feature, which is the cheapest fix there is.
The Pull Request Was Written by an Assistant
Two questions belong here, and either can replace something else in the loop if time is short.
A lot of the diffs reaching you were drafted by a coding assistant. What changes about review?
The trust model doesn’t change, since it was never “the author is careful,” but the volume and the plausibility do. The code shows up fast, reads well, compiles, and carries the same missing-authorization assumptions a tired human would have written, sometimes alongside a dependency that doesn’t exist or was registered last week. Good candidates describe where they’d spend their reading time, mostly on authorization, secrets, new packages, and anything that touches money, and the two to be wary of are the one who bans assistants outright and the one who thinks review is now somebody else’s job.
Our support bot can issue refunds through a tool call. Threat-model it.
The OWASP Top 10 for LLM Applications 2025 supplies the vocabulary, with prompt injection at LLM01, improper output handling at LLM05, and excessive agency at LLM06, but you don’t need the numbers from the candidate. You need the instinct that a model’s output is untrusted input and that permission to move money belongs in the code that executes the tool, not in a sentence in the prompt.
The best answer I’ve had on this was a question. Who sets the refund limit, the model or the code?
Questions About the Other Humans
An application security engineer who can’t persuade developers is an expensive scanner, and two questions get at that without having a technical answer.
The first is to tell you about a fix a team refused to make, and what happened next. Strong candidates have a specific story and it doesn’t end with a hero in it, because they compromised, escalated once, or found a smaller change the team would accept, and if the story is mostly about how foolish the team was, you’ve learned something about month three. The second asks how they’d find out whether a developer is right that a finding isn’t exploitable. You’re listening for “I’d try to exploit it,” and for the candidate who admits the developer is sometimes right and the finding gets closed with a note, which is worth more than any dashboard.
If you sell software to federal agencies there’s a reason beyond culture to care about the review habit, since the NIST Secure Software Development Framework, SP 800-218, includes a practice called PW.7 on reviewing or analyzing human-readable code to find vulnerabilities and verify security requirements. A candidate who has run that process before and can describe the evidence it left behind is worth more to you than one who can’t.
What Mid-Level and Senior Answers Sound Like
The same exercises work at both levels, and the difference is how much help the candidate needs and how far they run once they’ve found something.
| Round | Mid-level | Senior | Walk-away answer |
|---|---|---|---|
| Pull request | Finds the missing ownership check once you ask who owns the invoice | Finds it unprompted, moves the fix into the shared layer, asks what else follows the same pattern | Add input validation to everything |
| Threat model | Lists sensible threats after you point at the trust boundary | Starts with questions to the product owner, ranks the risks, names one to accept | A completed STRIDE grid and no questions |
| AI-generated code and LLM features | Knows prompt injection and treats model output as untrusted | Puts the authorization in the code that runs the tool, and says where review time goes | Ban the assistants, or trust the model |
| Developers | Files clear tickets and follows up | Has a story where a smaller fix beat the ideal one | A story where the team was the problem |
If your panel is all developers, that’s fine and sometimes better, since developers are the audience for this person’s work. Ask each of them one thing after the round, which is whether they’d have taken that pull request comment seriously, and give the answer a lot of weight.
Don’t Filter Them All Out
The ISC2 2025 Cybersecurity Workforce Study found 59% of respondents reporting critical or significant skills needs, up from 44% the year before, and application security was cited by 28%, fourth behind AI at 41%, cloud security at 36%, and risk assessment at 29%. People who are strong in this seat are scarce and get recruiter messages every week, so a loop that takes three weeks and four rounds will lose them to a company that moved faster.
Our IT searches average 17 days from intake to hire, and 92% of KORE1 placements are still in the seat a year later. This role runs longer than our average, closer to six weeks in my experience, and most of the gap is clients waiting a week between rounds, so if you can run the two exercises above in a single half-day, do.
The engagement tends to follow the work. A bounded job, say a threat model on one product plus a backlog cleanup with a start and an end, fits contract staffing, while somebody who will own the program for the next three years is a direct hire. Pay is in the hire guide linked earlier, and a number for your metro is a minute away in the KORE1 salary benchmark tool, ideally pulled before the first interview and not after the first rejection. How the number moves with the lifecycle stages a seat owns is broken out in our application security engineer salary guide.
Asked on Intake Calls, Almost Word for Word
Take-home or live?
Live, at forty-five minutes, on a pull request from your own repository.
A take-home rewards people with free evenings and tells you nothing about how someone thinks out loud, which is most of the job. Candidates also prefer the live version, since they’re usually in two or three other processes and won’t give you a weekend.
Can candidates use an AI assistant during the exercise?
Allow it if you’d allow it on the job, and watch what they do with the output.
A candidate who pastes the pull request into a chat window and reads back whatever it says has shown you exactly what you were afraid of. One who uses it to look up an unfamiliar library and keeps reading the code themselves has shown you something good, and either way you learn more than a ban would have taught you.
Our code is Java and the best candidate writes Go. Do we pass?
Not automatically. Authorization bugs, design flaws, and failing open look much the same in any language, and a few weeks of reading your framework is a smaller gap than a missing instinct.
Where it does matter is memory-unsafe code. If you write C or C++ and the candidate has never touched either, that’s a real gap, and the loop should say so.
How is this different from the security engineer loop?
The security engineer loop spreads across design, cloud, identity, and incident response, while this one stays inside the code your own developers write and the features they’re about to build.
Plenty of teams run both rounds for a hire who’ll cover more than one area, and our cloud security engineer interview questions cover the infrastructure side if that’s where your gaps are.
Should we start with a contractor?
Often, yes, when the need is a defined backlog or a one-time design review and you haven’t yet shown you can keep an AppSec program staffed.
The other case is a genuine unknown, whether you need a full-time owner at all. A six-month contract answers that without a salary commitment, and plenty of clients convert the good ones.
Run the Exercise on Your Own Team First
Before any candidate sees it, hand the pull request to your best senior developer and give them the same forty-five minutes. If they spot the authorization gap in ten, the exercise is too easy, and if they never find it, either the problem is hidden too well or you’ve learned something about your codebase that no candidate was going to tell you.
If you’d rather hand the whole screen to people who run it every week, talk to our security recruiting team and tell us the language your services run on and whether you take card payments, since those two answers shape who we send. Our cybersecurity staffing practice takes it from there.
