Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

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.

5537 vulnerabilities reference this CWE, most recent first.

GHSA-WCCV-R56Q-VWMW

Vulnerability from github – Published: 2022-02-12 00:00 – Updated: 2023-06-23 21:30
VLAI
Details

Improper access control vulnerability in Samsung SearchWidget prior to versions 2.3.00.6 in China models allows untrusted applications to load arbitrary URL and local files in webview.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-24923"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-11T18:15:00Z",
    "severity": "LOW"
  },
  "details": "Improper access control vulnerability in Samsung SearchWidget prior to versions 2.3.00.6 in China models allows untrusted applications to load arbitrary URL and local files in webview.",
  "id": "GHSA-wccv-r56q-vwmw",
  "modified": "2023-06-23T21:30:26Z",
  "published": "2022-02-12T00:00:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24923"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/serviceWeb.smsb?year=2022\u0026month=2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WCGJ-F865-C7J7

Vulnerability from github – Published: 2025-12-10 21:31 – Updated: 2025-12-11 15:48
VLAI
Summary
Improper Request Caching Lookup in the Auth0 Next.js SDK
Details

Description

When using affected versions of the Next.js SDK, simultaneous requests on the same client may result in improper lookups in the TokenRequestCache for the request results.

Am I Affected?

You are affected if you meet the following preconditions: - Applications using the auth0/nextjs-auth0 SDK with a singleton client instance, versions 4.11.0, 4.11.1, and 4.12.0.

Affected product and versions

Auth0/nextjs-auth0 v4.11.0, v4.11.1, and v4.12.0.

Resolution

Upgrade Auth0/nextjs-auth0 version to v4.11.2 or v4.12.1

Acknowledgements

Okta would like to thank Joshua Rogers (MegaManSec) for their discovery and responsible disclosure.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@auth0/nextjs-auth0"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.11.0"
            },
            {
              "fixed": "4.11.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@auth0/nextjs-auth0"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.12.0"
            },
            {
              "fixed": "4.12.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-67490"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-10T21:31:24Z",
    "nvd_published_at": "2025-12-10T23:15:48Z",
    "severity": "MODERATE"
  },
  "details": "### Description\nWhen using affected versions of the Next.js SDK, simultaneous requests on the same client may result in improper lookups in the TokenRequestCache for the request results.\n\n### Am I Affected?\nYou are affected if you meet the following preconditions:\n- Applications using the auth0/nextjs-auth0 SDK with a singleton client instance, versions 4.11.0, 4.11.1, and 4.12.0.\n\n### Affected product and versions\nAuth0/nextjs-auth0 v4.11.0, v4.11.1, and v4.12.0.\n\n### Resolution\nUpgrade Auth0/nextjs-auth0 version to v4.11.2 or v4.12.1\n\n### Acknowledgements\nOkta would like to thank Joshua Rogers (MegaManSec) for their discovery and responsible disclosure.",
  "id": "GHSA-wcgj-f865-c7j7",
  "modified": "2025-12-11T15:48:10Z",
  "published": "2025-12-10T21:31:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/auth0/nextjs-auth0/security/advisories/GHSA-wcgj-f865-c7j7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67490"
    },
    {
      "type": "WEB",
      "url": "https://github.com/auth0/nextjs-auth0/commit/26cc8a7c60f4b134700912736f991a25bd6bbf0b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/auth0/nextjs-auth0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper Request Caching Lookup in the Auth0 Next.js SDK"
}

GHSA-WCQR-6GJ6-96WC

Vulnerability from github – Published: 2024-12-12 03:33 – Updated: 2025-11-04 00:32
VLAI
Details

The issue was addressed with improved permissions logic. This issue is fixed in macOS Sequoia 15.2, macOS Sonoma 14.7.2. An app may be able to modify protected parts of the file system.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-54495"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-12T02:15:30Z",
    "severity": "MODERATE"
  },
  "details": "The issue was addressed with improved permissions logic. This issue is fixed in macOS Sequoia 15.2, macOS Sonoma 14.7.2. An app may be able to modify protected parts of the file system.",
  "id": "GHSA-wcqr-6gj6-96wc",
  "modified": "2025-11-04T00:32:14Z",
  "published": "2024-12-12T03:33:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54495"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/121839"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/121840"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Dec/7"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Dec/8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WCR3-9X4C-F5GJ

Vulnerability from github – Published: 2026-06-26 22:31 – Updated: 2026-06-26 22:31
VLAI
Summary
Blnk has an API key authorization bypass in owner and scope enforcement
Details

Blnk API key endpoints had an authorization issue that allowed non-master API keys to perform key-management actions outside their intended authorization boundary.

In affected versions, API key operations trusted caller-controlled request values for owner and scope decisions. As a result, a non-master API key could potentially manage keys for another owner by supplying a different owner value, or create a more privileged API key by requesting broader scopes than it already had.

This has been fixed by deriving the effective owner from the authenticated API key and enforcing scope coverage checks when creating new keys.

Details

The API key authorization flow previously trusted request data supplied by the caller when deciding which owner a key-management operation applied to and which scopes could be granted.

This meant a non-master API key could potentially:

  • create API keys for another owner
  • list API keys belonging to another owner
  • revoke API keys belonging to another owner
  • create a new API key with broader scopes than the caller’s own scopes

The patched version changes this behavior for non-master API keys:

  • the effective owner is derived from the authenticated API key
  • caller-supplied owner values are no longer trusted for authorization decisions
  • cross-owner key operations are rejected with 403 Forbidden
  • requested scopes must be covered by the caller’s existing scopes
  • master-key behavior is unchanged

Impact

A non-master API key with access to API key management endpoints could potentially perform unauthorized key-management operations across owners or escalate its permissions by creating a new API key with broader scopes.

Deployments using API keys for programmatic key creation, listing, or revocation should upgrade.

Affected versions

Versions up to and including v0.14.2 are affected.

Patched versions

This issue is fixed in v0.14.3.

Users should upgrade to v0.14.3 or later.

Workarounds

If developers cannot upgrade their applications immediately, restrict access to API key management endpoints to trusted master keys only.

Where possible, disable or block non-master API key access to key creation, listing, and revocation endpoints until the patched version is deployed.

Credits

Blank thanks @Shivam8584 for identifying and fixing this issue.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.14.2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/blnkfinance/blnk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.14.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T22:31:03Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Blnk API key endpoints had an authorization issue that allowed non-master API keys to perform key-management actions outside their intended authorization boundary.\n\nIn affected versions, API key operations trusted caller-controlled request values for owner and scope decisions. As a result, a non-master API key could potentially manage keys for another owner by supplying a different owner value, or create a more privileged API key by requesting broader scopes than it already had.\n\nThis has been fixed by deriving the effective owner from the authenticated API key and enforcing scope coverage checks when creating new keys.\n\n## Details\n\nThe API key authorization flow previously trusted request data supplied by the caller when deciding which owner a key-management operation applied to and which scopes could be granted.\n\nThis meant a non-master API key could potentially:\n\n- create API keys for another owner\n- list API keys belonging to another owner\n- revoke API keys belonging to another owner\n- create a new API key with broader scopes than the caller\u2019s own scopes\n\nThe patched version changes this behavior for non-master API keys:\n\n- the effective owner is derived from the authenticated API key\n- caller-supplied owner values are no longer trusted for authorization decisions\n- cross-owner key operations are rejected with `403 Forbidden`\n- requested scopes must be covered by the caller\u2019s existing scopes\n- master-key behavior is unchanged\n\n## Impact\n\nA non-master API key with access to API key management endpoints could potentially perform unauthorized key-management operations across owners or escalate its permissions by creating a new API key with broader scopes.\n\nDeployments using API keys for programmatic key creation, listing, or revocation should upgrade.\n\n## Affected versions\n\nVersions up to and including `v0.14.2` are affected.\n\n## Patched versions\n\nThis issue is fixed in `v0.14.3`.\n\nUsers should upgrade to `v0.14.3` or later.\n\n## Workarounds\n\nIf developers cannot upgrade their applications immediately, restrict access to API key management endpoints to trusted master keys only.\n\nWhere possible, disable or block non-master API key access to key creation, listing, and revocation endpoints until the patched version is deployed.\n\n## Credits\n\nBlank thanks @Shivam8584 for identifying and fixing this issue.",
  "id": "GHSA-wcr3-9x4c-f5gj",
  "modified": "2026-06-26T22:31:03Z",
  "published": "2026-06-26T22:31:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/blnkfinance/blnk/security/advisories/GHSA-wcr3-9x4c-f5gj"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/blnkfinance/blnk"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Blnk has an API key authorization bypass in owner and scope enforcement"
}

GHSA-WCWW-4VRG-9H35

Vulnerability from github – Published: 2022-05-13 01:49 – Updated: 2022-05-13 01:49
VLAI
Details

Apps Manager included in Pivotal Application Service, versions 1.12.x prior to 1.12.22, 2.0.x prior to 2.0.13, and 2.1.x prior to 2.1.4 contains an authorization enforcement vulnerability. A member of any org is able to create invitations to any org for which the org GUID can be discovered. Accepting this invitation gives unauthorized access to view the member list, domains, quotas and other information about the org.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-1278"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-05-11T20:29:00Z",
    "severity": "MODERATE"
  },
  "details": "Apps Manager included in Pivotal Application Service, versions 1.12.x prior to 1.12.22, 2.0.x prior to 2.0.13, and 2.1.x prior to 2.1.4 contains an authorization enforcement vulnerability. A member of any org is able to create invitations to any org for which the org GUID can be discovered. Accepting this invitation gives unauthorized access to view the member list, domains, quotas and other information about the org.",
  "id": "GHSA-wcww-4vrg-9h35",
  "modified": "2022-05-13T01:49:38Z",
  "published": "2022-05-13T01:49:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1278"
    },
    {
      "type": "WEB",
      "url": "https://pivotal.io/security/cve-2018-1278"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/104227"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WCXR-59V9-RXR8

Vulnerability from github – Published: 2026-03-13 20:55 – Updated: 2026-04-01 00:06
VLAI
Summary
`OpenClaw: session_status` let sandboxed subagents access parent or sibling session state
Details

Summary

The built-in session_status tool did not enforce the intended session-visibility boundary. A sandboxed subagent could supply another session's sessionKey and inspect or modify state outside its own sandbox scope.

Impact

This allowed a sandboxed child session to read parent or sibling session data and, in affected releases, update the target session's persisted model override.

Affected versions

openclaw <= 2026.3.8

Patch

Fixed in openclaw 2026.3.11 and included in later releases such as 2026.3.12. Session visibility checks now enforce the sandbox boundary before reading or mutating session state.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.3.8"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32918"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-13T20:55:19Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThe built-in `session_status` tool did not enforce the intended session-visibility boundary. A sandboxed subagent could supply another session\u0027s `sessionKey` and inspect or modify state outside its own sandbox scope.\n\n### Impact\n\nThis allowed a sandboxed child session to read parent or sibling session data and, in affected releases, update the target session\u0027s persisted model override.\n\n### Affected versions\n\n`openclaw` `\u003c= 2026.3.8`\n\n### Patch\n\nFixed in `openclaw` `2026.3.11` and included in later releases such as `2026.3.12`. Session visibility checks now enforce the sandbox boundary before reading or mutating session state.",
  "id": "GHSA-wcxr-59v9-rxr8",
  "modified": "2026-04-01T00:06:27Z",
  "published": "2026-03-13T20:55:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-wcxr-59v9-rxr8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32918"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.3.11"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-session-sandbox-escape-via-session-status-tool"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "`OpenClaw: session_status` let sandboxed subagents access parent or sibling session state"
}

GHSA-WF4M-RQ68-3MFC

Vulnerability from github – Published: 2023-01-12 06:30 – Updated: 2023-01-18 21:30
VLAI
Details

Incorrect Authorization check affecting all versions of GitLab EE from 13.11 prior to 15.5.7, 15.6 prior to 15.6.4, and 15.7 prior to 15.7.2 allows group access tokens to continue working even after the group owner loses the ability to revoke them.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-4167"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-12T04:15:00Z",
    "severity": "HIGH"
  },
  "details": "Incorrect Authorization check affecting all versions of GitLab EE from 13.11 prior to 15.5.7, 15.6 prior to 15.6.4, and 15.7 prior to 15.7.2 allows group access tokens to continue working even after the group owner loses the ability to revoke them.",
  "id": "GHSA-wf4m-rq68-3mfc",
  "modified": "2023-01-18T21:30:21Z",
  "published": "2023-01-12T06:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4167"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-4167.json"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/367740"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WF74-667M-QG32

Vulnerability from github – Published: 2022-06-07 00:00 – Updated: 2022-06-15 00:00
VLAI
Details

Gradle Enterprise through 2022.2.2 has Incorrect Access Control that leads to code execution.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-30586"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-06-06T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "Gradle Enterprise through 2022.2.2 has Incorrect Access Control that leads to code execution.",
  "id": "GHSA-wf74-667m-qg32",
  "modified": "2022-06-15T00:00:23Z",
  "published": "2022-06-07T00:00:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30586"
    },
    {
      "type": "WEB",
      "url": "https://security.gradle.com"
    },
    {
      "type": "WEB",
      "url": "https://security.gradle.com/advisory/2022-09"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WFFG-FW64-5MVQ

Vulnerability from github – Published: 2025-11-11 15:31 – Updated: 2025-11-11 15:31
VLAI
Details

A security issue was discovered within Verve Asset Manager allowing unauthorized read-only users to read, update, and delete users via the API.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-11862"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-11T14:15:34Z",
    "severity": "HIGH"
  },
  "details": "A security issue was discovered within Verve Asset Manager allowing unauthorized read-only users to read, update, and delete users via the API.",
  "id": "GHSA-wffg-fw64-5mvq",
  "modified": "2025-11-11T15:31:20Z",
  "published": "2025-11-11T15:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11862"
    },
    {
      "type": "WEB",
      "url": "https://www.rockwellautomation.com/en-us/trust-center/security-advisories/advisory.SD1759.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:H/SC:N/SI:L/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-WFH5-X68W-HVW2

Vulnerability from github – Published: 2022-05-24 22:29 – Updated: 2025-11-04 21:30
VLAI
Details

Bluetooth Mesh Provisioning in the Bluetooth Mesh profile 1.0 and 1.0.1 may permit a nearby device (participating in the provisioning protocol) to identify the AuthValue used given the Provisioner’s public key, and the confirmation number and nonce provided by the provisioning device. This could permit a device without the AuthValue to complete provisioning without brute-forcing the AuthValue.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-26559"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-24T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "Bluetooth Mesh Provisioning in the Bluetooth Mesh profile 1.0 and 1.0.1 may permit a nearby device (participating in the provisioning protocol) to identify the AuthValue used given the Provisioner\u2019s public key, and the confirmation number and nonce provided by the provisioning device. This could permit a device without the AuthValue to complete provisioning without brute-forcing the AuthValue.",
  "id": "GHSA-wfh5-x68w-hvw2",
  "modified": "2025-11-04T21:30:25Z",
  "published": "2022-05-24T22:29:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26559"
    },
    {
      "type": "WEB",
      "url": "https://kb.cert.org/vuls/id/799380"
    },
    {
      "type": "WEB",
      "url": "https://www.bluetooth.com/learn-about-bluetooth/key-attributes/bluetooth-security/reporting-security"
    },
    {
      "type": "WEB",
      "url": "https://www.kb.cert.org/vuls/id/799380"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
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.
Mitigation
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].

Mitigation MIT-4.4
Architecture and Design

Strategy: Libraries or Frameworks

  • 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].
Mitigation
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.
Mitigation
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.

No CAPEC attack patterns related to this CWE.