Meta Application & API Security interview questions

Three bugs, one cause. The answer that scores names the cause, explains why parameters are structural, and lands on why prompts have no parameters.

'Sanitise input' is the answer that fails. The interviewer wants encoding at the point of output, for the specific context, with CSP behind it.

Reading files top to bottom finds style issues. A security review starts from sources, sinks and the checks between them, and AI code adds a new source.

Scanners rarely find it, because every request looks valid. Finding it at scale is a testing design problem, not a scanning problem.

Three browser rules that candidates mix up constantly. The JWT follow-up exposes whether you know which one depends on cookies.

A strict CSP blocks many XSS payloads but not all, and DOM XSS has paths it cannot see. The scored answer explains what a nonce-based policy stops, where it fails, and why Trusted Types targets the DOM sinks.

Model a bounded reservation workflow, run an offline invariant fixture, and reason about retries, contention, immutable intent and uncertain external outcomes.

Small requests that trigger large work are the cheapest denial of service. The scored answer finds the multipliers, bounds every one, and adds the AI-era ones.

URL validation is where string checks fail most visibly. The scored answer parses, resolves and allowlists, then tests the classic bypasses.

A practical round that tests clean code and detection judgement together. The scored answer parses defensively, picks a signal that separates stuffing from a forgetful user, and names what it misses.

Every attribute answers one question: over which connections, to which scripts, from which sites and to which hosts does this cookie travel? Get those four right and most session theft paths close.

The user clicks a button on your page while believing they are on someone else's. The fix is a response header that tells the browser who may frame you, not script that tries to escape the frame.

No SQL does not mean no injection. When a query is a JSON object, the attack is sending an object where the code expected a string.

CORS never blocks a request from being sent. It decides whether another site's script may read the answer, and with credentials allowed, that answer contains the logged-in user's data.

The login form is the front door, but attackers use the side doors: reused passwords, guessable recovery, and MFA that can be phished or reset by a support agent.

CSRF defences stop other sites from acting as the user. XSS is not another site: it is code running inside yours, with everything your own pages can do.

GraphQL lets clients ask for exactly what they want, which includes things you did not mean to give them and queries that cost a thousand times a normal one. The scored answer moves controls to where GraphQL actually decides things.

A browsing tool is a URL fetcher whose destination is chosen by text anyone can write. The interviewer wants the defences in the tool and the network, not the prompt.

The model is not the attacker, but whoever wrote the document it just read might be. Every argument in a tool call is untrusted input.

The format is the bug. JSON cannot call functions; pickle is designed to. The AI version is the model checkpoint you just downloaded.

File tools take paths from the model, and the model takes ideas from whatever it read. A string check for '..' is not confinement.

The model did not write malicious HTML on its own; a web page it summarised did. Then the conversation was shared, and the renderer trusted it.

Work through tenant, role, object and field checks, then extend the review to bulk exports, permission changes and resource budgets with executable acceptance cases.