API Security Patterns — Series 2

Preview — 3 of 10 questions

A public API supports both simple API keys (a single static string a developer includes in requests) and OAuth 2.0 access tokens (short-lived, issued after a user consents to specific scopes). What's the key architectural difference, and when is each more appropriate?

AAn API key is a single, typically long-lived credential identifying the calling application/developer itself — simple to issue and use, but if leaked it grants whatever access that key has until it's manually revoked, and it doesn't represent a specific end-user's consent. An OAuth access token instead represents a specific user's delegated permission for specific scopes, is normally short-lived (limiting the damage window if leaked), and can be issued/revoked per user-application pairing — making OAuth the better fit when an app needs to act on behalf of a specific user with limited, revocable permissions, while API keys suit simpler server-to-server or application-level identification

BAPI keys and OAuth access tokens provide identical security guarantees and are simply two different names for the same underlying mechanism

COAuth access tokens never expire, while API keys always expire within 60 seconds of being issued

DAPI keys can only be used for read-only operations, while OAuth tokens can only be used for write operations

An OAuth-based system issues a short-lived access token alongside a longer-lived refresh token, which the client uses to obtain new access tokens without re-authenticating. What's refresh token rotation, and what problem does it address?

ARefresh token rotation means the access token is refreshed on a fixed daily schedule regardless of actual usage, with no relationship to the refresh token at all

BRefresh token rotation means physically rotating the storage location of tokens between different database servers on a schedule

CRefresh token rotation eliminates the need for access tokens entirely, since the refresh token alone is used for every single API call

DRefresh token rotation means issuing a brand-new refresh token every time the old one is used to get a new access token, and invalidating the previous refresh token immediately — so each refresh token is single-use. This addresses the risk of a stolen refresh token being used repeatedly and silently by an attacker: if a rotated refresh token is ever reused (a strong sign it was stolen and both the legitimate client and an attacker are now racing to use the same one), the system can detect that reuse and revoke the entire token family, cutting off the attacker

A browser blocks a JavaScript request from https://app.example.com to https://api.example.com by default, unless the API explicitly allows it via CORS headers. Why does this same-origin restriction exist, and what does a CORS header like Access-Control-Allow-Origin actually do?

ACORS restrictions exist purely as an accidental browser bug that developers must work around, with no intentional security purpose

BThe browser's default same-origin policy exists to prevent a malicious website from silently using a logged-in user's browser to make authenticated requests to other sites on the user's behalf (e.g., reading their bank account data) and reading the response — since the browser automatically attaches cookies to requests. Access-Control-Allow-Origin (and related CORS headers) let a server explicitly declare which other origins are permitted to make cross-origin requests to it and read the response, opting into cross-origin access rather than having the browser block it by default

CCORS headers encrypt the request body so that only the intended server can decrypt it, and have no relationship to which origins are allowed to make requests

DOnce a server sets Access-Control-Allow-Origin: *, it becomes impossible for that server to ever restrict cross-origin access again, permanently

Answer all 10 questions (7 more), see explanations for every answer, and track your score.