# Application security engineer interview questions and answers

Source: https://www.techinterview.org/post/3233477872/application-security-engineer-interview-questions/
Updated: 2026-11-05 · techinterview.org

Application security (AppSec) and product security engineer interviews test web vulnerabilities, OAuth, JWT and TLS, plus three hands-on rounds: live secure code review, a threat model or security design, and, at Meta and in tooling roles, LeetCode-easy coding. Strong answers give root cause, attack, defense and exploit conditions in OWASP Top 10:2025 terms, where SSRF has joined CSRF and IDOR under A01.

An AppSec loop rarely asks you to define XSS. It asks how to fire one without a script tag, then what a CSP nonce needs to stop it. Anuraag Baishya's [2024 product security job-hunt write-up](https://medium.com/@anuraagbaishya/tales-from-my-product-security-job-hunt-part-1-interview-types-f5fa49fcd2fd) says mid-level interviewers want "in-depth" answers, not definitions. The [security engineer interview guides](/security-engineer-interview-guides/) hub collects the company loops.

## The rounds AppSec candidates report

Round write-ups from 2021 to 2025 pair web-vulnerability follow-ups with three hands-on rounds. The one that catches people out is live secure code review in an unfamiliar language: a 2024 [Meta](/companies/meta-facebook/) [new-grad candidate](https://leetcode.com/discuss/interview-experience/4965161/) got "a vulnerable server side codebase in PHP," and a Meta native-track screen was "a large C++ code snippet" reviewed by hand. Say the language is new and ask about syntax. Narrate line by line, trace each untrusted input to its sink, and test whether the mitigation holds: a filter that strips `../` once turns `....//` back into `../`. Practice the bug classes on PortSwigger's free [Web Security Academy](https://portswigger.net/web-security), which an [Atlassian](/companies/atlassian/) listing names, and reading code on the [secure code review interview](/post/3233477869/secure-code-review-interview/) page.

One 2024 Meta screen spent about 30 minutes on CoderPad ("check if a string was a palindrome") and 30 on securing a new login page. The new-grad onsite added 3Sum and a `cd(pwd, path)` variant of Simplify Path, mostly [two pointers and string handling](/post/3233474160/coding-interview-two-pointers-sliding-window-patterns-array-string-problems-fast-slow-pointer-variable-window/). Elsewhere, Baishya saw coding mostly in tooling roles.

"In nearly every company I interviewed with, I had to threat model a given system," Baishya writes, either abstract or from an architecture diagram. On Meta's new-grad design prompt, an online coding exam platform, the interviewer answered clarifying questions with "You tell me, you are the architect here." Both are worked in full on the [threat modeling interview](/post/3233477868/threat-modeling-interview/) and [security system design interview](/post/3233477870/security-system-design-interview/) pages.

| AppSec interview question family | Question as reported or listed | What a strong answer includes |
| --- | --- | --- |
| Web, browser, OAuth and crypto knowledge | "How can you induce XSS without script tags?" | Root cause, attack, defense and exploit conditions, in OWASP Top 10:2025 and current RFC terms |
| Live secure code review | PHP, Java, Python or C++, often unfamiliar | Input-to-sink tracing, named bug classes, missing controls, a fix per finding |
| Threat modeling | A reservation system, or a messaging site from its diagram | STRIDE or another named method, trust boundaries, stated assumptions |
| Security design | Secure an online coding exam platform | Clarifying questions, an authorization model, secrets handling, defended trade-offs |
| Tooling and supply chain | Write static analysis rules; triage SAST output | Real findings vs false positives, A03:2025 Software Supply Chain Failures |
| Bug bounty triage | Validate an external vulnerability report | Reproduce it, score with CVSS, check logs for prior exploitation, drive the fix |
| Secure SDLC | Engaging engineering teams on security goals | Security champions, checks inside release readiness, plain language |

## Why 2021 category names date your answers

The current web edition is [OWASP Top 10:2025](https://top10.owasp.org/2025/), released late 2025, and much prep material still prints the 2021 list. SSRF lost its own entry and joined [CSRF](/post/3233474144/system-design-web-security-owasp-xss-csrf-sql-injection-cors-csp-authentication-authorization-jwt-oauth/) (CWE-352) and IDOR in A01 Broken Access Control. [XSS](/post/3233475082/frontend-security-xss-csrf-csp/) is in A05 Injection, and insecure deserialization (CWE-502) in A08 Software or Data Integrity Failures. A03 is Software Supply Chain Failures, and A10, Mishandling of Exceptional Conditions, covers failing open.

## Worked answers to the most-asked questions

### "What are the types of XSS? How can you mitigate DOM XSS?"

All XSS is untrusted data reaching an HTML or JavaScript sink without context-correct encoding. Stored and reflected XSS pass through the server. DOM XSS can stay in the browser: `location.hash` flows into `innerHTML`, and the server never receives a payload after the `#`. "Without script tags" wants event handlers and URL schemes: `<img src=x onerror=alert(1)>`, a `javascript:` link. Fix DOM XSS by dropping dangerous sinks (`textContent` over `innerHTML`) and adding Trusted Types and a strict CSP. Nonces must be fresh per response, at least 128 bits from a secure RNG, and never cached. `HttpOnly` stops cookie theft, not actions taken as the user.

### "What is the same origin policy and how does CORS relate to it?"

Baishya calls this "another favorite." SOP lets a page send requests anywhere but read responses only from its own scheme, host and port. CORS lets a server relax that for origins it names, so it never adds protection and is no CSRF defense. Reflecting any `Origin` with `Access-Control-Allow-Credentials: true` hands every site the user's authenticated responses. Allowing `null` admits sandboxed iframes. A suffix check like `endsWith("example.com")` accepts `evilexample.com`. And `*` can't be combined with credentials, which is why lazy configs reflect instead.

### "How can you prevent CSRF in a case where we cannot use CSRF tokens?"

CSRF works because browsers attach cookies to cross-site requests, so it needs cookie-based sessions, a state-changing request with predictable parameters, and a cookie sent cross-site. Without tokens, lead with Fetch Metadata: reject state-changing requests unless `Sec-Fetch-Site` is `same-origin` (allow `same-site` only if every subdomain is trusted), fall back to an `Origin` check where the header is missing, and require a custom header on API calls, which a cross-site form can't set and a cross-site fetch can only send after passing your CORS policy. A signed double-submit cookie is still a token, just stateless. [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) says SameSite "does not replace a proper CSRF defense": Lax still sends cookies on top-level GETs, and same-site means the registrable domain, so a sibling subdomain can attack.

### "What is the principle behind using prepared statements for SQL injection mitigation?"

Concatenation lets data change a query's structure; a prepared statement is parsed before parameters bind as values, so they can't become SQL. Its limits: identifiers and `ORDER BY` direction need an allowlist, raw ORM fragments reopen the hole, and second-order injection fires when a stored value is concatenated later.

### IDOR vs missing function-level access control vs privilege escalation

A 2020 candidate-compiled list asks for the difference. IDOR is a missing check on which object: `GET /invoices/1043` returns someone else's invoice. Missing function-level access control is a missing check on which action: a regular user can call the admin refund endpoint. Privilege escalation is the result, horizontal or vertical, and either bug can cause it. Deny by default and enforce ownership where data is fetched, scoping every query to the caller's user or tenant. Unguessable IDs slow enumeration but fix nothing. Test with two accounts: replay one user's requests with the other's session.

### "SSRF and mitigations"

[A 2021 Blind commenter](https://www.teamblind.com/post/appsec-interviews-irk4wpst) called it "a very common question these days." A server fetching user-controlled URLs reaches what it can: cloud metadata at 169.254.169.254, internal admin panels. Allowlist, validate the resolved IPs and connect to the one you checked: "domain allowlisting alone does not prevent DNS rebinding" ([OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html)). Disable redirects, reject URLs two parsers read differently, require IMDSv2 and segment the fetcher; more in the [SSRF and cloud metadata](/post/3233477308/ssrf-cloud-metadata-interview/) post.

### Securing a new login page and storing passwords

This is the Meta screen prompt; its follow-ups covered hashing and salting, rate limits, error disclosure and sessions. Hash with Argon2id or bcrypt, both salted and slow on purpose. Rate-limit per account and IP; hard lockout stops guessing but lets anyone lock a victim out, so prefer backoff and step-up checks. Credential stuffing (one try per account, many IPs) slips past both, so screen passwords against breach lists and offer MFA. Return the same error, in the same time, for an unknown user and a wrong password. Issue a new session ID at login to stop fixation. Cite [ASVS 5.0.0](https://asvs.owasp.org/) (May 2025) for the full checklist.

### "How would you attack the OAuth workflow?"

Loose redirect URI matching (prefix, wildcard) lets an attacker route the authorization code to their host. Without `state` or PKCE binding the flow to the browser that started it, they can inject their own code and log the victim into the attacker's account. [RFC 9700](https://www.rfc-editor.org/rfc/rfc9700.html) (January 2025) sets the rules: public clients MUST use PKCE, confidential clients are RECOMMENDED to, and authorization servers MUST support it; clients SHOULD NOT use the implicit grant; the resource owner password credentials grant MUST NOT be used; redirect URIs match exactly; access tokens should be audience-restricted and sender-constrained (DPoP or mTLS).

The JWT follow-up is algorithm confusion: the service expects RS256, the library trusts the `alg` header, and the attacker signs an HS256 token with the public key as the HMAC secret, or sends `none`. [RFC 8725](https://www.rfc-editor.org/rfc/rfc8725.html) answers: "Each key MUST be used with exactly one algorithm." It also says human-memorizable passwords "MUST NOT be directly used" as HS256 keys. A01:2025 wants stateless JWTs short-lived, which raises [whether you can revoke a JWT](/post/3233477260/revoke-jwt-oauth-interview-questions/); see also [API security interview questions](/post/3233460404/api-security-interview-questions/).

### "Explain a TLS handshake"

Baishya calls it "the most commonly asked question." [Answer with TLS 1.3](/post/3233477262/tls-handshake-interview/): ephemeral ECDHE key shares in the two hellos give forward secrecy, the encrypted certificate and CertificateVerify prove the server holds the key for that hostname, and Finished authenticates the transcript so tampering fails.

## Tooling, supply chain and bug bounty triage

Atlassian's listings name Burp Suite, ZAP, Semgrep and Snyk, and ask you to "distinguish actionable findings from false positives." An [Adobe](/companies/adobe/) hiring-manager round [reported on Blind](https://www.teamblind.com/post/Adobe-Product-Security-Engineer-QQ4BJk4z) in 2024, Adobe's only public round report, was "mainly on source code review and how to write rules to detect issues from code level," so practice turning a hand-found bug into a rule that finds its siblings. Supply chain maps to A03:2025, but the one candidate-reported question we found, on dependency confusion, is an unverified 2021 snippet.

Reported bug bounty questions are about triage, not program design. Adobe's 2026 senior ProdSec post wants a "frontline responder" for external reports, including "AI related reports," scored with CVSS v3.1; know v4.0 too, FIRST's current version since November 2023. Reproduce the report, check for duplicates, score it and drive the fix with the owning team. For the 2020 list's "how will you investigate if this was not exploited already," start the log window when the vulnerable code shipped, not when the report arrived, and confirm retention reaches that far. Search for the bug class, not the reporter's payload, and for behavior like one session walking many IDs. If the logs stop short, say exploitation can't be ruled out. For AI reports, see [AI security interview questions](/post/3233477871/ai-security-interview-questions/).

Loops also test whether engineers can work with you: Baishya was asked to threat model "without using too much security jargon." Amazon wants [STAR answers](/post/3233460379/behavioral-interview-questions-2026-star-method-amazon-leadership-principles-and-winning-answers/) tied to its [Leadership Principles](/post/3233474665/amazon-leadership-principles-cheat-sheet/); see the [Amazon security engineer interview loop](/post/3233477867/amazon-security-engineer-interview-loop/).

## Meta and Atlassian product security interviews

Meta has the most firsthand evidence, and it is thin. Its Instagram Product Security Engineer post (October 2025) asks for "manual design and implementation reviews of web, mobile, and native code". The onsite details above rest on one 2024 new-grad report; senior Meta onsites aren't publicly documented.

Atlassian's engineering interview page has no security track; the only public reports are 2023 campus rounds with vulnerable snippets and an XSS payload task.

If you have one week, spend most of it reading vulnerable code aloud in a language you don't write; that round rewards only practice.