Least Privilege and Blast Radius
Least privilege is the practice of giving code, users, services, and web origins only the access they need, while blast radius is the damage possible when that access is abused. Together they describe both prevention and containment: reduce unnecessary authority, then make any compromise stop at the smallest useful boundary.
This matters because modern systems are full of intentional holes in isolation. Browsers normally separate origins by scheme, host, and port, but applications often need controlled exceptions for login flows, embedded content, frontend to API calls, and cross-window messages. Each exception is a new path an attacker can try to use after XSS, a leaked token, a hostile subdomain, or a confused redirect.
Mechanically, least privilege is enforced by narrowing the capability being granted. A CORS rule names which origin may read a response. A postMessage call names the target origin, and the receiver checks event.origin before acting. An IAM policy names allowed actions and resources. OAuth uses exact redirect URIs and state values. The common pattern is the same: bind permission to a specific caller, operation, and resource.
The trade-off is operational friction. Narrow permissions require knowing what each component genuinely needs, updating policies as the product changes, and debugging failures caused by missing access. Overly tight rules can break deployments, while broad temporary exceptions tend to become permanent. The honest answer is usually that privilege depends on the threat model, the sensitivity of the data, and how quickly teams can safely change configuration.
Engineers meet this in CORS headers, postMessage handlers, cookie domains, CSRF defences, OAuth configuration, cloud IAM, Kubernetes RBAC, CI service accounts, and storage bucket policies. A common misunderstanding is that cross-origin embedding is harmless because the response cannot always be read. It can still send authenticated requests, load executable script, leak through callbacks, or widen compromise from one page to a larger trust boundary.
Common questions
- How does CORS affect blast radius?
- CORS decides which origins may read a browser response that same-origin policy would otherwise hide. Allowing one trusted frontend is a narrow exception. Allowing arbitrary origins, or combining broad origins with credentialed requests, means a malicious site may be able to read data through the victim’s browser or through attacker-supplied bearer credentials.
- Why is postMessage risky if it is an intended browser feature?
- postMessage is safe only when both sides treat it as a capability handoff. The sender should use a specific targetOrigin, not a wildcard, and the receiver should verify event.origin before trusting the message. Without those checks, any frame or popup with a reference may send commands or receive sensitive data.
- Is least privilege just about cloud IAM?
- No. Cloud IAM is a visible example, but the same idea applies to browsers, service accounts, cookies, OAuth redirects, subdomains, database roles, and deployment automation. Any boundary that grants access can be scoped narrowly or broadly. Blast radius is the practical question: what can an attacker reach if this boundary fails?