1. Question and Context
A product needs to share an invoice, file, or one-time action. The link itself carries the access capability, so the server does not need to identify a logged-in account first. The interview focus is when this model is reasonable and how to handle links being copied, logged, or forwarded.
2. What the Interviewer Is Evaluating
- Whether you distinguish capability URLs, login sessions, and OAuth bearer-token trust models.
- Whether your threat model includes URL leakage through logs, history, analytics, referrers, and screenshots.
- Whether you design short expiry, least privilege, single use, or audience binding.
- Whether you support per-link revocation, bulk revocation, and auditability instead of only rotating a global key.
The W3C capability-URL guidance says that granted access must be revocable if a capability URL leaks. OWASP explicitly advises against putting passwords, API keys, or security tokens in URLs, so a capability URL needs a clear risk boundary and compensating controls.
3. Clarifying Questions Before You Answer
- Is the resource public, low sensitivity, or personal, financial, or regulated?
- Must the visitor sign in, and will the link cross organizational boundaries?
- Is access a one-time download, a short window, or long-lived collaboration?
- After leakage, must you revoke one link, one user, or the entire resource?
4. A 30-Second Answer Framework
Use suitability, token, leakage, revocation, and alternative.
I would use a capability URL only for low-frequency, auditable access where possession is acceptable, and scope it to one resource and a short window. The token must be high entropy and unpredictable; the server stores only a hash and records creation, use, and revocation. I would set Referrer-Policy: no-referrer and keep it out of logs and third-party analytics. Sensitive resources should use authenticated authorization, with the capability URL limited to a one-time invitation or download credential.
5. Step-by-Step Deep Dive
Step 1: Choose the Right Trust Model
A capability URL means possession grants authority; it does not prove an account identity. It fits low-sensitivity sharing, one-time downloads, or registration-free invitations. It is a poor fit for fine-grained membership, long-term audit requirements, or strong identity assurance. For an OAuth bearer token, prefer the Authorization header; RFC 6750 lists a URI query parameter as possible but higher-risk transport.
Step 2: Minimize the Capability
Bind the token to a resource, action, and audience. Add a short expiration, single-use marker, and rate limit; for forwardable workflows, require recipient confirmation or login before redemption. Generate tokens with a cryptographically secure random source and store only a hash so a database leak does not immediately become a usable credential.
Step 3: Control URL Leakage
OWASP notes that URLs enter server logs, browser history, and proxy records. After receiving the token, the landing page should exchange it for a short-lived session over a secure request and remove it from the address bar. Use a strict referrer policy and avoid third-party resources that receive the token. Email, screenshots, and chat tools can still expose a link, so do not place long-lived high-privilege access in it.
Step 4: Implement Precise Revocation and Audit
Record the creator, resource, action, expiry, last use, and revocation time for each token. Check revocation before every redemption or download; per-link revocation must not depend on rotating a global key. Audit successful, failed, repeated, and revoked uses with reasons so leakage and abuse can be investigated.
6. High-Quality Sample Answer
I would first classify sensitivity and lifetime. A public handbook needs no capability URL. A low-sensitivity invoice for external review may use one, while a sensitive financial report should require login and organization permissions.
>
For the acceptable case, I generate at least 128 bits of randomness and bind the token to one resource, one action, and a 24-hour window. The database stores only a token hash, status, and audit fields. A successful redemption is marked used immediately, and the download endpoint checks expiry and revocation every time. The response sets Referrer-Policy: no-referrer; after redemption, the token is removed from the address bar and the page avoids third-party resources that could receive a referrer.
>
Users can revoke one link and administrators can revoke links by resource; revocations and repeated use are audited. If the product later needs collaboration, I would migrate to authenticated authorization and membership permissions instead of extending the capability URL into a permanent bearer token. This keeps sharing convenient while limiting leakage to one resource and a bounded time.
7. Common Failure Modes
- Treating a long link as security while ignoring logs, history, and forwarding.
- Using predictable resource IDs or auto-incrementing tokens.
- Putting a long-lived, high-privilege bearer token in a query parameter.
- Supporting only global key rotation and no per-link revocation.
- Leaving the token in the address bar after redemption while loading third-party images or analytics.
8. Follow-Up Questions and Responses
Follow-up 1: Why store only a token hash?
The token is the holder’s credential. If database read access leaks, a plaintext token is immediately usable. Hashing lets the server compare a submitted value without turning static storage into a credential dump.
Follow-up 2: Does single use make refresh fail?
Use the one-time token to exchange for a short-lived session; refresh uses that session rather than redeeming the original link again. If redemption succeeds but the response is lost, provide a constrained idempotent redemption result without reopening long-lived authority.
Follow-up 3: When should you abandon capability URLs entirely?
Use authenticated authorization and server-side permissions when the resource is highly sensitive, membership must be managed continuously, caller identity must be proven, or the organization requires centralized revocation and audit.