Amazon 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.

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.

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.

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.

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.

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

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

Verify the sender protocol, persist recoverable intake, distinguish delivery retries from business effects, and work through two offline fixtures and crash boundaries.

Two injection classes where a parser or template engine does far more than the developer intended. The scored answer explains the dangerous feature in each and turns it off.

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

Each tool sees the application from a different angle and has a blind spot where another looks. The scored answer maps bug classes to tools and builds a pipeline that does not drown developers.

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.

Two servers disagree about where one request ends and the next begins. The scored answer explains the ambiguity, what an attacker gains, and why consistent parsing and HTTP/2 end to end fix it.

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

Generated code ships faster, which is the point and the risk. The scored answer names the specific failure modes and keeps the normal controls working at the new speed.

An LLM reviewer reads every change, which no human team can, and is confidently wrong some of the time. The scored answer places it as a triage layer, measures it, and protects it from the code it reads.

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.

An easy coding warm-up with traps a security engineer should spot: symlinks, huge files, unreadable files and paths outside the tree. The scored answer handles each and tests it.

A classic coding round with a security twist: the crawler fetches URLs that strangers wrote. The scored answer gets concurrency right, then adds scope, limits and SSRF protection.

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.

Logging in is one moment; a session lasts hours or months. Most session bugs live in what happens between: identifiers that never change, timeouts nobody enforces, and logouts that only clear the browser.

No error messages does not mean no injection. And the sort column is the one place where 'just use parameters' does not work, so you need a different fix.

An ORM parameterises the queries it builds. It cannot protect the queries you build around it, or the data you trusted because it came from your own database.

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.

Interviewers ask for the list to see whether you are current. They ask how you would use it to see whether you understand it is an awareness document, not a standard.

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.

Every check passed and every write succeeded. The money still left twice, because the check and the write were two steps and another request got between them.

Most database breaches are not clever. They are a reachable database, an over-privileged account, a leaked credential or an exposed backup.

The same injection bug can leak one table or hand over the server. The difference is decided by grants made long before the bug was written.

Managed databases remove patching chores but add a control plane: whoever can call the cloud API can often copy, share or expose the whole database.

These breaches rarely involved exploits. Databases built for trusted networks were put on the internet with no password, and automated scripts found them within hours.

Every database encryption option protects against someone. The question is whether it protects against the attacker you are worried about, and most only stop thieves of disks and backups.

A bot can send exactly the headers a browser sends. It is much harder for it to send the same TLS handshake, run the same JavaScript and behave like a person. Bot management stacks those differences.

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.

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.

The commonest serious bug in AI tools is the oldest: fetching an object by ID without checking who is asking. The scored answer finds it, fixes it at the data access, and tests across users and tenants.

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.

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.