Implementing Secure Access Controls in Applications

Learn how to design and enforce robust access control policies to protect sensitive data within applications.

0 likes
15 views

Rule Content

---
name: Implementing Secure Access Controls in Applications
version: "1.0"
category: Security
description: Learn how to design and enforce robust access control policies to protect sensitive data within applications.
rules:
  - id: access-control-trusted-objects
    description: "Use only trusted system objects, such as server-side session objects, for making access authorization decisions."
    severity: high
    pattern: |
      // Code pattern that uses untrusted objects for access control
    fix: |
      // Corrected code using trusted system objects for access control
    references:
      - "https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable/en/02-checklist/05-checklist"

  - id: centralized-access-control
    description: "Implement a single, site-wide component to check access authorization, including libraries that call external authorization services."
    severity: medium
    pattern: |
      // Code pattern with decentralized access control checks
    fix: |
      // Refactored code using a centralized access control component
    references:
      - "https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable/en/02-checklist/05-checklist"

  - id: enforce-authorization-controls
    description: "Enforce authorization controls on every request, including those made by server-side scripts, 'includes,' and requests from rich client-side technologies like AJAX and Flash."
    severity: high
    pattern: |
      // Code pattern missing authorization checks on certain requests
    fix: |
      // Updated code with authorization checks on all requests
    references:
      - "https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable/en/02-checklist/05-checklist"

  - id: segregate-privileged-logic
    description: "Segregate privileged logic from other application code to prevent unauthorized access to sensitive operations."
    severity: high
    pattern: |
      // Code pattern with mixed privileged and non-privileged logic
    fix: |
      // Refactored code with segregated privileged logic
    references:
      - "https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable/en/02-checklist/05-checklist"

  - id: restrict-access-resources
    description: "Restrict access to files, resources, URLs, functions, and data to only authorized users."
    severity: high
    pattern: |
      // Code pattern with unrestricted access to resources
    fix: |
      // Updated code with access restrictions based on user authorization
    references:
      - "https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable/en/02-checklist/05-checklist"

  - id: consistent-access-control
    description: "Ensure that server-side implementation and presentation layer representations of access control rules match."
    severity: medium
    pattern: |
      // Code pattern with inconsistent access control between layers
    fix: |
      // Synchronized access control rules between server-side and presentation layers
    references:
      - "https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable/en/02-checklist/05-checklist"

  - id: encrypt-client-stored-state
    description: "If state data must be stored on the client, use encryption and integrity checking on the server side to prevent tampering."
    severity: high
    pattern: |
      // Code pattern storing unencrypted state data on the client
    fix: |
      // Updated code with encrypted and integrity-checked client-stored state data
    references:
      - "https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable/en/02-checklist/05-checklist"

  - id: enforce-business-rules
    description: "Enforce application logic flows to comply with business rules, ensuring that application behavior aligns with business requirements."
    severity: medium
    pattern: |
      // Code pattern with logic flows not aligned with business rules
    fix: |
      // Refactored code to enforce business rule compliance
    references:
      - "https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable/en/02-checklist/05-checklist"

  - id: limit-transactions
    description: "Limit the number of transactions a single user or device can perform within a given period to deter automated attacks."
    severity: medium
    pattern: |
      // Code pattern without transaction limits
    fix: |
      // Updated code with transaction limits per user/device
    references:
      - "https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable/en/02-checklist/05-checklist"

  - id: revalidate-user-authorization
    description: "If long authenticated sessions are allowed, periodically re-validate a user's authorization to ensure their privileges have not changed."
    severity: medium
    pattern: |
      // Code pattern with long sessions without re-validation
    fix: |
      // Updated code with periodic re-validation of user authorization
    references:
      - "https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable/en/02-checklist/05-checklist"