Weakness (CWE)
CWE-863: Incorrect Authorization
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
How to prevent it (5 mitigations)
-
Architecture and Design
Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
-
Architecture and Design
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
-
Architecture and Design
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
-
Architecture and Design
For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
-
System Configuration, Installation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
Source: MITRE CWE-863
2,080 results · Clear filters · Feed
-
Medium 4.3
Backstage: Incorrect authorization in search engine permission filtering
Backstage is an open framework for building developer portals. Prior to 2.1.6 in @backstage/plugin-search-backend and 1.8.7 in @backstage/plugin-search-backend-module-elasticsearch, search engine permission filtering could return documents denied by policy. A…
-
Medium 5.0
Backstage: Sensitive information disclosure in Kubernetes resource queries
Backstage is an open framework for building developer portals. Prior to 0.21.9, the @backstage/plugin-kubernetes-backend package is affected by sensitive information disclosure in kubernetes resource queries. An authenticated user holding the standard Kuberne…
-
Medium 6.5
PraisonAI: Platform members can delete owner issue dependencies through member-owned related issues
PraisonAI is a multi-agent teams system. In `praisonai-platform` prior to version 0.1.9, issue dependency deletion can be authorized against the wrong side of a dependency edge. A workspace member cannot delete a dependency through the owner-created issue end…
-
Medium 4.3
Obot 0.26.0 before 0.26.2 Authorization Bypass via vMCP Profile Prompts and Resources
Obot 0.26.0 before 0.26.2 contains an authorization bypass vulnerability that allows authenticated users matching any vMCP profile to reach prompts and resources of ungranted components. Because profiles were enforced only on tools, attackers can access promp…
-
Medium 6.3
wolfSSH SSH client accepts unsolicited forwarded-tcpip channel opens without an authorization check
In wolfSSH through 1.5.0 built with --enable-fwd, DoChannelOpen() in src/internal.c gates only direct-tcpip channel opens with the forwarding policy callback. forwarded-tcpip opens are admitted without an authorization check and are not capped in number, allo…
-
Medium 4.3
Gitea profile feed disclosure bypassing user visibility
Requesting a user or organization profile page (`GET /{username}`) with an `Accept: application/rss+xml` or `Accept: application/atom+xml` header returned the owner's activity feed without the visibility check that the profile page and the `.rss` and `.atom` …
-
Medium 5.4
Gitea push-to-create bypass of FORCE_PRIVATE policy
With `[repository] FORCE_PRIVATE = true`, Gitea creates new repositories as private, but the post-receive hook still applied the `repo.private=false` push option to an empty repository created by push. Any user who can create repositories could make their new…
-
Medium 4.3
Gitea issue attachment API allows changing comment attachments
The Gitea API routes for issue attachments (`/api/v1/repos/{owner}/{repo}/issues/{index}/assets/{attachment_id}`) also accepted attachments that belong to comments on the issue. Because the author of an issue may edit and delete the issue's attachments, a use…
-
Medium 4.3
Backstage: Inconsistent catalog property permission evaluation
Backstage is an open framework for building developer portals. Prior to 3.9.1, the @backstage/plugin-catalog-backend package is affected by inconsistent catalog property permission evaluation. In deployments that use affected value-based catalog permission co…
-
Medium 4.9
Gitea push mirror API bypass of DISABLE_NEW_PUSH policy
The Gitea API endpoint for creating push mirrors (`POST /api/v1/repos/{owner}/{repo}/push_mirrors`) checked only whether mirroring was enabled and not the `[mirror] DISABLE_NEW_PUSH` setting that the web interface enforces. A repository administrator could th…
-
Medium 5.4
Backstage: Improper authorization in GitLab organizational user ingestion
Backstage is an open framework for building developer portals. Prior to 0.8.7, the @backstage/plugin-catalog-backend-module-gitlab package is affected by improper authorization in gitlab organizational user ingestion. Deployments that enable GitLab organizati…
-
Medium 6.4
Backstage: Scaffolder credential handling may allow unintended GitHub authentication fallback
Backstage is an open framework for building developer portals. Prior to 1.54.6, scaffolder source-control actions may not consistently enforce intended credential boundaries. An authenticated user could cause an affected action to fall back to broader integra…
-
Medium 4.3
Backstage: Incorrect authorization in scaffolder task listing
Backstage is an open framework for building developer portals. Prior to 4.1.0, the @backstage/plugin-scaffolder-backend package is affected by incorrect authorization in scaffolder task listing. An authenticated internal user may be able to view metadata for …
-
Medium 6.5
Backstage: Inconsistent repository filtering in Bitbucket Server catalog event updates
Backstage is an open framework for building developer portals. From 0.4.0 until 0.5.15, the @backstage/plugin-catalog-backend-module-bitbucket-server package is affected by inconsistent repository filtering in bitbucket server catalog event updates. Deploymen…
-
Medium 4.8
Backstage: Inconsistent credential enforcement for overlapping proxy routes
Backstage is an open framework for building developer portals. From 0.5.0 until 0.6.18, the @backstage/plugin-proxy-backend package is affected by inconsistent credential enforcement for overlapping proxy routes. An operator can configure overlapping proxy pa…
-
Medium 6.5
Incorrect Authorization in Kibana Leading to Sensitive Information Disclosure
Incorrect Authorization (CWE-863) in Kibana can lead to sensitive information disclosure via Accessing Functionality Not Properly Constrained by ACLs (CAPEC-1). An authenticated Kibana user with limited Fleet management privileges could access sensitive crede…
-
Medium 5.4
Incorrect Authorization in Elasticsearch Leading to Unauthorized Data Stream Modification
Incorrect Authorization (CWE-863) in Elasticsearch can lead to unauthorized data stream modification via Accessing Functionality Not Properly Constrained by ACLs (CAPEC-1). An authenticated user with sufficient privileges over a single resource could use the …
-
Medium 4.3
Gitea private repository access retained after rejected transfer
When a private repository is transferred to a user who lacks access, Gitea grants that recipient temporary read access as a collaborator so they can review the repository. Rejecting or cancelling the transfer did not revoke this collaboration, so the named re…
-
Medium 5.4
Incorrect authorization in WebAppInstalls in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to spoof UI…
-
Medium 5.4
Incorrect authorization in PermissionElement in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to bypas…
-
Medium 4.3
Incorrect authorization in API in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to bypass web origin p…
-
Medium 4.3
Incorrect authorization in DevTools in Google Chrome prior to 155.0.8059.39 allowed a remote attacker leveraging social…
-
Medium 4.3
Incorrect authorization in Scheduling in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to bypass web o…
-
Medium 5.4
Incorrect authorization in DevTools in Google Chrome prior to 155.0.8059.39 allowed a local attacker to bypass system a…
-
Medium 6.5
Incorrect authorization in FontAccess in Google Chrome prior to 155.0.8059.39 allowed a remote attacker who had comprom…
-
Medium 4.2
Incorrect authorization in Unbounded Element in Google Chrome prior to 155.0.8059.39 allowed a remote attacker who had …
-
Medium 4.3
Incorrect authorization in Media in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to leak cross-origin…
-
Medium 6.5
Incorrect authorization in Network in Google Chrome prior to 155.0.8059.39 allowed a remote attacker who had compromise…
-
Medium 4.2
Incorrect authorization in WebShare in Google Chrome on on Android prior to 155.0.8059.39 allowed a remote attacker who…
-
Medium 5.9
Incorrect authorization in PDF in Google Chrome on on Android prior to 155.0.8059.39 allowed a local attacker leveragin…
-
Medium 5.4
Incorrect authorization in Input in Google Chrome prior to 155.0.8059.39 allowed a remote attacker leveraging social en…
-
Medium 6.5
Incorrect authorization in PermissionElement in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to poten…
-
Medium 5.4
Incorrect authorization in Browser in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to spoof address b…
-
Medium 4.3
Incorrect authorization in Extensions in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to obtain cross…
-
Medium 4.8
Incorrect authorization in Extensions in Google Chrome prior to 155.0.8059.39 allowed a remote attacker leveraging soci…
-
Medium 6.5
Incorrect authorization in GetUserMedia in Google Chrome prior to 155.0.8059.39 allowed a remote attacker who had compr…
-
Medium 6.1
Incorrect authorization in Mobile in Google Chrome on on iOS prior to 155.0.8059.39 allowed a remote attacker leveragin…
-
Medium 6.5
Incorrect authorization in USB in Google Chrome prior to 155.0.8059.39 allowed a remote attacker leveraging social engi…
-
Medium 6.5
Incorrect authorization in Permissions in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to bypass syst…
-
Medium 6.5
Incorrect authorization in Passwords in Google Chrome on on iOS prior to 155.0.8059.39 allowed a remote attacker to byp…