Skip to content

Insecure Access Control

Insecure Access Control

Description

The application does not enforce proper access control, allowing an attacker to access unauthorized data or perform unauthorized business functions.

Access control vulnerabilities may be caused by:

  • Referencing content using primary keys and lack of validation of the content access permissions.
  • CORS misconfiguration is allowing unauthorized API access.
  • Metadata manipulation, such as replaying or tampering with access control tokens.

Recommendation

Access control is only effective if enforced in trusted server-side code or server-less API, where the attacker cannot modify the access control check or metadata.

  • Except for public resources, deny by default.
  • Implement access control mechanisms once and re-use them throughout the application, including minimizing CORS usage.
  • Model access controls should enforce record ownership rather than accepting that the user can create, read, update, or delete any record.
  • Domain models should enforce unique application business limit requirements.
  • Disable web server directory listing and ensure file metadata (e.g., .git) and backup files are not present within web roots.
  • Log access control failures and alert admins when appropriate (e.g., repeated failures).
  • Rate limit API and controller access to minimize the harm from automated attack tooling.
  • JWT tokens should be invalidated on the server after logout. Developers and QA staff should include functional access control units and integration tests.

Standards

  • CWE_TOP_25:
    • CWE_276
  • OWASP_ASVS_L1:
    • V4_1_5
  • OWASP_ASVS_L2:
    • V4_1_5
    • V1_4_4
    • V1_10_1
  • OWASP_ASVS_L3:
    • V4_1_5
    • V1_4_4
    • V1_10_1
  • PCI_STANDARDS:
    • REQ_2_2
    • REQ_6_2
    • REQ_6_3
    • REQ_6_4
    • REQ_7_3
    • REQ_11_3
  • SOC2_CONTROLS:
    • CC_2_1
    • CC_4_1
    • CC_6_1
    • CC_7_1
    • CC_7_2
    • CC_7_4
    • CC_7_5