Security basics

Most design interviews do not want a threat-model workshop. They do want to hear that you noticed who is allowed to do what, and what happens when the input is hostile. Five sentences cover the usual probe.

Identity and authorization

Authenticate at the edge (session cookie or a short-lived token). Authorize in the service that owns the object, every time: this user, this invoice, this action. The vulnerable pattern is “they are logged in, and they named an id.” Admin paths are a separate role, not a hidden URL.

Multi-tenant systems (a lab, a merchant, a company) should carry the tenant in the token and in the query. A missing tenant predicate is a data leak, not a performance bug. If you shard by tenant, isolation gets easier. If you do not, tests have to prove a query cannot cross tenants.

Data

TLS everywhere outside a tightly controlled mesh. Encrypt sensitive columns or disks if the data is regulated, and do not invent your own cipher. Secrets come from a secret manager, rotate, and never land in logs or images.

Collect less. Resumes, recordings, and payment data need a retention clock and an access log. “We keep everything forever in the data lake” is a privacy incident with a delay.

Input

Validate size, type, and schema at the edge. Parse documents asynchronously so a malicious file spends a worker’s time, not your web server’s. Parameterize SQL. Escape output. Treat anything a user uploaded, including text that will be shown to a model, as data.

If a model can call tools, the tool layer enforces policy. The model does not get a raw shell, a raw SQL connection, or the ability to email an arbitrary address because a PDF said “ignore previous instructions.”

Abuse

Rate-limit authentication and expensive endpoints. Use unguessable ids so a crawler cannot walk /users/1 through /users/1000000. Record audit events for money movement, permission changes, and data export. Assume a script will find any endpoint you ship.

Say these in proportion to the product. A URL shortener needs abuse and auth. A payments or hiring system needs all of the above, and you should bring it up before you are asked.