Security, Abuse, and Privacy

The guest is still authenticated

Consider a multi-tenant document system. A consultant has an account in the product and was invited to a client’s workspace for a week. The engagement ends, an administrator removes the guest, and the consultant opens an old search result.

The request arrives over TLS with a valid session. The document store is encrypted. Neither fact answers the consequential question: may this actor read this document now?

Suppose the document API rejects the read, but the search service still returns the title and a cached snippet. A notification link still reveals the document name. A support operator can open the content through an internal tool without recording a case. The primary authorization check worked; the system did not.

This is why a security pass should follow an action, not inventory controls. For one valuable operation, name the actor, asset, trust crossings, copies, ways to repeat it at scale, and evidence left afterward. Then decide which harm must be prevented on the request path and which can be detected and repaired later.

Start with an actor, an asset, and an action

“Users must be authenticated” is too broad to design from. The consultant case is precise enough:

actor     consultant with a valid account and a revoked workspace membership
action    read document 42 through an old search result
asset     private document content and the fact that the document exists
boundary  public client -> search -> document service -> tenant data
copies    cache, search index, notifications, logs, exports, backups

Now the architecture has something to defend. It needs to reject the document read, stop the search result and snippet, avoid revealing the title through a notification or error message, and leave evidence that the attempt occurred. If the same consultant tries thousands of guessed identifiers, the design must also prevent enumeration from becoming cheap.

This framing is a small threat model, not a claim to have completed a security review. In an interview, it gives the discussion a boundary and lets the interviewer change one condition: make the link public, make the guest active, make the actor a support operator, or make revocation race with an in-flight export. Each change should alter the decision.

Authorization is a resource decision

Authentication establishes an identity and properties of the session. Authorization combines that identity with the proposed action, the resource, its tenant, its current state, and sometimes the actor’s purpose.

authorize(actor, action, resource, tenant, state, purpose) -> allow | deny

A role can narrow the search space—workspace administrators may invite members—but it rarely settles a real resource decision. A user with an editor role may edit one document, read another, and have no knowledge that a third exists. A suspended document may reject writes from an otherwise authorized editor. A support operator may see billing metadata for a live case without receiving blanket permission to read customer documents.

For document 42, the service derives the tenant and document identity from the stored resource. It does not accept a client-supplied tenant_id as proof of scope. It then checks current membership and the document’s access policy. A public link, if the product allows one, is a separate grant with its own capabilities, expiry, and revocation behavior; it is not a reason to skip the resource lookup.

Keep the decisive check close to the resource or data-access boundary. UI controls improve usability, and a gateway can reject obviously invalid calls, but neither can protect a service reached through a worker, another API, or a new client. Default denial also matters during uncertainty. If the membership service is unavailable, a private document read should not become public for the sake of apparent availability.

Caching authorization can reduce latency, but revocation gives the cache a correctness deadline. A five-minute membership cache means a revoked guest may retain access for nearly five minutes unless invalidation or a versioned policy closes the window. State that window as a security and product choice rather than describing cached checks as simply fast.

The tenant boundary follows every copy

The document row is only the beginning of tenant isolation. Document 42 may also appear in a cache entry, a search posting list, a queue message, an email job, an analytics event, an export, a backup, and a support console. Each copy needs enough trusted context to preserve the boundary.

Cache keys include tenant scope as well as the resource identity. Queue messages carry a server-derived tenant, actor or service identity, action, and stable resource ID. Workers re-check authority when delayed work can outlive a grant. Search either maintains permission-aware indexes or treats the index as a candidate generator and authorizes results before returning titles, counts, or snippets. The first choice makes reads faster but revocation and index updates harder; the second keeps policy fresher but adds query work and can still leak through counts or timing if filtering is careless.

Isolation in storage should match the risk and operating model. Shared tables with tenant-scoped keys can be efficient, provided queries, indexes, jobs, and tests make cross-tenant access difficult. Separate schemas, databases, keys, or compute pools can reduce the blast radius for high-risk tenants, but they add provisioning, migration, analytics, backup, and support complexity. “Database per tenant” is not automatically safer if a shared admin tool or search system can still cross every tenant.

Encryption protects another boundary. TLS protects data moving between clients, services, and dependencies; storage and backup encryption reduce some forms of exposure at rest. The design still needs authorization, least privilege, key separation where warranted, secret rotation, and control over who can decrypt or export data. An encrypted search index served to the wrong tenant is a confidentiality failure with excellent cryptography.

Abuse begins where repetition changes the economics

One forbidden read is an authorization problem. Ten million document-ID probes are also an abuse problem. The action has become cheap for the attacker and expensive or revealing for the product.

Place controls before expensive work and count at the boundary that represents the scarce resource. The document system may combine per-account, per-tenant, per-network, and per-device limits because any one identity is easy to rotate. It can detect unusual enumeration, harden cursors and identifiers, slow suspicious clients, require stronger verification, or suspend an export while preserving ordinary reads. A quota after the search fan-out or export job has started protects little.

Different flows need different evidence and recovery:

• credential stuffing appears as login attempts spread across accounts and calls for login-specific velocity limits and account protection;
• invite and message spam calls for progressive trust, send limits, duplicate detection, reporting, and moderation queues;
• scraping appears through enumeration, pagination, or export-like reads and calls for scoped quotas, anomaly detection, and tighter bulk-export grants;
• fraud appears through linked payment, coupon, refund, or payout behavior and may require holds, reconciliation, risk review, and idempotent state changes.

A generic rate limit misses those semantics. It may punish a large legitimate tenant while an attacker distributes requests across many accounts. Good abuse controls combine immediate harm reduction with a recovery path: challenge, review, appeal, account restoration, or reconciliation.

Not every suspicious action should block inline. Permission checks, password resets, high-risk exports, and payment authorization usually need a decision before the effect. Spam scoring, content classification, trust updates, and some fraud enrichment can run asynchronously when the product can quarantine, reverse, or review the result. The choice exposes the real trade-off among latency, false positives, user friction, operating cost, and the time harm may remain visible.

Privileged access is another product path

Internal does not mean trusted without limit. Support, moderation, analytics, and administrative tools cross a powerful boundary because they aggregate access that ordinary users do not have.

In the document system, support access begins with a case and the smallest data needed to resolve it. Sensitive access is time-limited, purpose-bound, and recorded. Impersonation is visibly distinct from normal login. Bulk export and cross-tenant actions may require approval. A break-glass path exists for rare emergencies, but using it produces conspicuous evidence and a review obligation rather than an invisible superuser session.

An audit event should answer who acted, through which identity and tool, on which tenant and resource, what they attempted, whether it succeeded, and which case or reason justified privileged access. It also needs a timestamp, request or workflow identifier, and enough policy context to investigate a later dispute. Do not turn the audit trail into a second leak by recording document contents, credentials, raw tokens, or unnecessary personal data. Protect its access and retention, and make silent alteration difficult enough for the risk being governed.

Audit is evidence, not prevention. A perfect record of an unauthorized export does not make the export acceptable. It helps investigate, attribute, notify, and improve after preventive controls fail.

Privacy decides what the system is allowed to remember

Security asks whether the consultant may read document 42. Privacy also asks why the product collected its contents, which derived systems received them, who can use them for another purpose, and when every copy should stop existing.

Begin before storage. Collect the least data that supports the product promise; use derived or masked values when raw data is unnecessary; classify sensitive fields; and keep document bodies, invitation secrets, credentials, and private comments out of general logs and metrics. Purpose matters for support and analytics access even when a broad technical permission could be granted.

Then give the data a lifecycle. Retention and deletion cover primary storage, search, caches, analytics, exports, and queued work, not just the canonical row. Backups require an honest caveat: immutable recovery media may retain a deleted record until the documented backup window expires. A restore procedure must reapply deletions or suppress restored data before it returns to ordinary use. Legal holds, contracts, and jurisdiction-specific duties can change these decisions; in an interview, state the engineering behavior and identify the obligation that still needs verification rather than inventing a universal rule.

For the revoked consultant, the lifecycle question is not whether the account still exists. It is whether membership removal withdraws future access, clears or expires derived grants, stops queued notifications, updates search, and leaves only the minimum evidence needed for security and operational purposes. It cannot recall a document or email already delivered outside the system, so the design must limit those exports before delivery and record when they occur.

Give the interview a causal security pass

When the architecture is on the board, a compact answer can follow one action all the way through:

I will trace a private document read. The client authenticates at ingress, but
the document service derives the workspace from the stored resource and checks
current membership, the document grant, resource state, and action. Tenant
scope follows the cache key, search index, queue messages, exports, and audit
events; search reauthorizes results so a stale index cannot return a revoked
guest's title or snippet.

For abuse, I protect enumeration, invitations, and exports before fan-out with
limits across actor, tenant, and network signals, then use review or stronger
verification for suspicious behavior. Support access is case-bound, temporary,
and audited. I minimize sensitive copies, keep content out of telemetry, and
define deletion across primary and derived stores, with a stated backup window
and restore-time re-deletion.

The main trade-offs are authorization and search latency, revocation freshness,
false positives, support capability, and the operating cost of stronger tenant
isolation. I would choose among them from the document sensitivity and tenant
promise, not claim that every control should be maximal.

That answer gives the interviewer useful ways to apply pressure. Make the guest link public. Let the policy service fail. Require an immediate revocation. Add a million-document export. Ask whether a support operator can recover a deleted document. Security judgment becomes visible in how the system’s behavior changes.

Practice the crossing

Choose a design you already know and one action whose misuse would cause real harm: read a private message, reset an account, apply a coupon, issue a refund, publish a post, or export a workspace.

Before naming controls, write the actor, asset, action, tenant or ownership boundary, and every derived copy. Trace the authorization decision, then make the action repeat ten thousand times. Decide which control must run before the effect, which signal can arrive later, what a false positive costs, and how the user recovers. Finally, remove access while work is in flight and explain what happens to caches, queues, indexes, exports, backups, and audit evidence.

For a harder variation, let the authorization service become unavailable while an administrator is revoking access. State which paths fail closed, which already accepted work may finish, how stale grants expire, and what evidence an operator needs before reopening the path.

Field reference

FRAME
  Name one actor, asset, action, trust crossing, and plausible harm.

AUTHORIZE
  Derive resource and tenant scope server-side. Decide from actor, action,
  resource, state, and purpose; define denial and revocation behavior.

FOLLOW
  Carry the boundary through caches, queues, search, analytics, notifications,
  exports, backups, and privileged tools.

LIMIT
  Find where repetition changes the economics. Put semantic quotas, friction,
  review, or holds before expensive or irreversible work.

MINIMIZE
  Collect and copy less. Protect data in transit and at rest, keep secrets and
  content out of telemetry, and restrict decryption and export.

EXPIRE
  Define retention, deletion, derived-store cleanup, backup windows, and
  restore-time handling.

PROVE
  Record safe, protected evidence of privileged access and high-risk changes.

TRADE
  Name latency, freshness, false positives, user recovery, operating cost, and
  the time harm may remain possible.

Security, abuse, and privacy are one boundary seen at different scales. Security asks whether this action is permitted. Abuse asks what changes when the action is repeated or coordinated. Privacy asks whether the system should possess and retain the data involved. A senior design keeps those answers attached to the architecture—and then makes their behavior observable. Observability and Operability takes up that evidence and the actions it should enable.