MITRE’s description of CWE-284: The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
Common consequences MITRE lists
- Other: Varies by Context
This broad entry covers any failure to restrict who can use a resource. MITRE discourages mapping findings to it; record the specific failure instead, such as missing authorization (CWE-862), incorrect authorization (CWE-863) or a user-controlled key (CWE-639).
- Define who may perform which action on which resource, and enforce it on the server for every request.
- Deny by default and grant each role and service only the access it needs.
- Classify findings by the specific failure so that the fix targets the real cause.
Guides on this site
Authorization models: RBAC, ABAC, ReBAC and policy as code you can test
Translate roles, attributes and relationships into explicit subject-action-resource decisions, prevent broken object level authorization (BOLA), and verify ownership and tenant boundaries with tests.
Enforce authorization for every object action
Authorize the authenticated subject, requested operation, and specific resource together; a valid login or unpredictable identifier is insufficient.
Authorize functions and fields as well as objects
Prevent mass assignment, sensitive-field exposure and administrative actions that a valid object lookup alone cannot protect.
Review cloud permissions and role trust together
Distinguish who can obtain a cloud identity from what that identity can do, then test the effective access path.
Protect the source repository: rulesets, reviews and signed commits
Configure the controls every repository that ships software needs: protected branches and tags, required review with CODEOWNERS, signed commits, secret push protection and account security, mapped to the SLSA Source track, the OpenSSF OSPS Baseline and Scorecard.
Harden managed Kubernetes on EKS, AKS and GKE
Know what your provider secures and what you still own, then lock down API access, cloud identity, nodes, pod privileges and admission with settings that are generally available in Kubernetes 1.37, checked against the CIS and NSA/CISA baselines.
Practice
- IDOR lab: Repair an invoice authorization bug · Browser lab
- Mass assignment lab: Update only the fields users may edit · Browser lab
- NetworkPolicy lab: Lock down a shop namespace · Browser lab
- IAM trust policy lab: Evaluate a role trust policy against the confused deputy · Browser lab
- Secure a real HTTP API · Local project
References
- CWE-284 in the MITRE CWE list (version 4.20)
- 2025 CWE Top 25 Most Dangerous Software Weaknesses (MITRE CWE Program)
List data from MITRE; the name, definition and consequences are from MITRE’s CWE 4.20 catalogue. A guide is listed as the main subject when the weakness is what the guide is about, and as covering it when a dedicated section or worked example addresses it.
CWE content: Copyright © 2006–2026, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation. CWE™ is free to use by any organization or individual for any research, development, and/or commercial purposes, per these CWE Terms of Use. Accordingly, The MITRE Corporation hereby grants you a non-exclusive, royalty-free license to use CWE for research, development, and commercial purposes. Any copy you make for such purposes is authorized on the condition that you reproduce MITRE’s copyright designation and this license in any such copy. CWE is a trademark of The MITRE Corporation. CWE Terms of Use.