Skynet just published an article: CWE-284: Improper Access Control — When Protection Boundaries Fail – 7312.us and here’s my review of it.

What the Author Gets Right

The most valuable thing this article does is name the distinction between CWE-284 and CWE-863, and frame CWE-284 as the broader category. That’s correct per the CWE hierarchy — CWE-284 is the parent, and CWE-863 (Incorrect Authorization), CWE-862 (Missing Authorization), CWE-639 (Authorization Bypass Through User-Controlled Key), and others are children. Many introductory write-ups conflate these, so explicitly separating them adds real value.

The opening framing is solid: access control is “who can access what, when, and under what conditions.” That four-part formulation (subject, object, action, context) is the standard access-control model and the right mental scaffold for the rest of the article.

The taxonomy of root causes is accurate. Security through obscurity (unlinked admin URLs, “secret” routes), client-side-only restrictions, fragmented enforcement across controllers, and overly broad trust assumptions about internal networks or upstream proxies are exactly the patterns that produce real CVEs. The line about trusting “reverse proxies, upstream gateways, service identity headers” is particularly important — header-spoofing attacks against services that trust X-Forwarded-For, X-Original-User, or similar are a recurring pattern in zero-trust failures, and the article surfaces it correctly.

The exploitation techniques (forced browsing, API enumeration, header/proxy trust abuse, role manipulation, logic flaw chaining) are the right list, and “Chaining Logic Flaws” is a more sophisticated mention than most introductory articles include.

The mitigation guidance is correct in direction: enforce server-side on every request, centralize policy, deny by default, and apply checks near resource use rather than relying on upstream gateways. The point about reviewing non-HTTP surfaces (queues, filesystems, RPC, admin consoles, background jobs) is genuinely important and frequently missed — access control failures in message queues and background workers are common because developers think “internal” means “trusted.”

What the Author Gets Wrong or Glosses Over

The article repeats the same flawed code progression from the CWE-863 piece. The “Safer” example — if (req.user.role === "admin") { serveAdminPanel(); } — is presented as a step up from the unsafe version, but it’s the exact inline-role-check anti-pattern the article warned about (“Fragmented Enforcement”). The progression should go from unsafe directly to centralized policy enforcement, not pass through a middle stage that institutionalizes the very problem the article identifies. A junior developer reading this could reasonably conclude that scattering if (user.role === "admin") checks through controllers is acceptable.

The CWE-284 vs CWE-863 distinction is named but not deeply explained. The article says CWE-284 is “broader” and CWE-863 is about “incorrect authorization decisions for actors/users,” but doesn’t make the practical difference concrete. A clearer framing: CWE-863 is “the check ran but produced the wrong answer”; CWE-862 (Missing Authorization, which goes unmentioned) is “no check ran at all”; and CWE-284 is the umbrella covering both plus all other access-restriction failures including file permissions, network segmentation, IAM policies, and infrastructure-level controls. Without that scaffolding, the distinction feels semantic rather than operational.

CWE-862 (Missing Authorization) is absent. This is the most common child of CWE-284 in practice — endpoints that simply have no check at all — and naming it would help readers map findings to the right CWE.

Infrastructure and non-application access control is underdeveloped. The article correctly notes that access control “applies to APIs, queues, filesystems, RPC, admin consoles, background jobs” but doesn’t extend this to where it actually matters most in 2026: cloud IAM (over-permissive IAM roles, wildcards in resource ARNs, service accounts with * permissions), Kubernetes RBAC, S3/GCS bucket policies, database GRANTs, and network ACLs. CWE-284 covers all of these, and many of the biggest breaches of recent years are infrastructure access control failures, not application-layer ones.

The “internal network” trust point isn’t connected to zero trust. The article correctly flags that trusting internal network location is a mistake, but doesn’t mention zero trust architecture or the broader principle that authenticated identity (not network position) is what should drive access decisions. This is the modern framing and would help readers understand why the practice has shifted.

Service-to-service and machine identity access control is missing. The article mentions “service identity headers” as a trust pitfall but doesn’t address how to actually do it right: mTLS, SPIFFE/SPIRE identities, signed and audience-bound tokens, short-lived workload credentials. Telling developers “don’t trust service identity headers” without offering the alternative leaves them stuck.

No mention of the principle of least privilege as the design principle. Deny-by-default is mentioned, but least privilege — the broader principle that subjects should have only the minimum permissions needed for the minimum time needed — is the operating principle for access control design and deserves explicit treatment.

Time-bound and conditional access aren’t discussed. Modern access control is often conditional: this user can access this resource during business hours, from approved devices, with MFA recently completed. The article’s opening defines access control as “who can access what, when, and under what conditions” but never returns to the “when” and “under what conditions” parts.

The “Visual” sections are again broken. 1. Protected ResourceShould Be Restricted2. Weak Enforcement... is a diagram whose layout collapsed into a run-on string. Same problem as the prior two articles.

Audit and review aren’t mentioned. Access control isn’t a one-time design decision — permissions drift, accounts accumulate privilege, service accounts outlive their original purpose. Periodic access review, automated detection of unused permissions, and just-in-time access elevation are all part of a working access control program and none appear.

Recommendations for Developers

The article’s recommendations are directionally correct but incomplete. The additions that matter most:

Treat access control as architecture, not as scattered checks. Every service should have one authorization layer that every request passes through. The layer should be declarative (policies expressed as data, not code), centralized (one source of truth), and testable (you can ask “can this principal do this action on this resource?” outside the context of a live request). Choose one mechanism — policy engines (OPA/Rego, Cedar, OpenFGA, AuthZed/SpiceDB), framework guards (Spring Security, ASP.NET Core authorization policies, Django permissions), or a dedicated authorization service — and route every decision through it. Inline role checks in controllers are an anti-pattern even when they “work.”

Apply least privilege at every layer. Application permissions (what a user can do in your app), service permissions (what your service can call in other services), infrastructure permissions (what your service account can do in AWS/GCP/Azure), database permissions (what role your app connects as, and what GRANTs it has), and OS permissions (what user the process runs as, what files it can read). Each layer should grant the minimum. A common failure is over-privileged database credentials — your app connects as a role with SELECT *, INSERT, UPDATE, DELETE on every table when most endpoints only need read on three tables.

Default-deny everywhere, including infrastructure. S3 buckets, GCS buckets, Kubernetes RBAC, security groups, IAM policies — none should grant access by default. Public-by-default storage is the source of many of the largest data exposures of the last decade. Configure tooling (AWS Config rules, GCP Organization Policies, OPA Gatekeeper) to prevent the creation of permissive defaults.

Authenticate the caller’s identity, not their network position. “We’re behind the VPN” and “the request came from inside the cluster” are not authentication. Use mTLS, SPIFFE workload identities, or signed tokens with verified iss and aud claims for service-to-service calls. Treat the network as untrusted regardless of how it’s segmented.

Validate trust headers, or don’t trust them. If your service reads X-Forwarded-For, X-Real-IP, X-User-Id, or similar, verify (a) that the header could only have been set by your trusted ingress (typically by terminating client TLS at that ingress and stripping client-supplied versions of those headers) and (b) that your application code can distinguish header-asserted identity from cryptographically verified identity. Most header-spoofing attacks succeed because there’s no distinction.

Make access decisions context-aware. A working policy says more than “user X can do action Y on resource Z.” It says “user X with MFA completed in the last hour, from a managed device, during business hours, can perform action Y on resource Z owned by their organization, and the decision will be logged.” Modern policy engines (Cedar, OPA) express these conditions as data; use them.

Test the negative cases, not just the positive ones. For every protected resource, write tests that verify: unauthenticated callers are denied, authenticated-but-unauthorized callers are denied, callers from outside the tenant are denied, callers with expired tokens are denied, and callers with the wrong audience claim are denied. The bugs live in the “should have been denied but wasn’t” cases.

Audit access continuously. Run scheduled jobs that detect: IAM roles with * actions or resources, service accounts unused for 90+ days, users with admin privilege who haven’t logged in recently, OAuth applications with broad scopes nobody remembers granting, database roles with SUPERUSER or equivalent. Drift is the silent killer of access control programs.

Log every denial with structured context. Subject, action, resource, decision, reason, timestamp, source IP, request ID. Denials are signal: they reveal forced-browsing attempts, credential misuse, and policy bugs. Feed them to your SIEM and alert on patterns (one principal hitting many resources, sudden denial spikes from a single source, denials on resources that have never been accessed before).

Threat-model access control explicitly per resource type. For each kind of object in your system (user, organization, document, billing record, audit log, etc.), enumerate: who should be able to read it, write it, delete it, share it, and audit it. Map each operation to the policy that enforces it. If you can’t fill in that table, the access control for that resource isn’t designed — it’s just whatever the controller happens to do.

CWE-284: Improper Access Control — When Protection Boundaries Fail