R176. Restrict system objects


The system must restrict access to system objects that have sensitive content. It should only allow access to authorized users.


Applications usually handle personal and confidential information, such as personal identifications, social security numbers, credentials and health histories. This data should be protected as a fundamental right, and therefore be stored and transmitted using secure mechanisms that prevent access to it by unauthorized actors. Furthermore, the access control model and role assignment policy must be implemented taking these restrictions into consideration.


  1. CIS Controls. 14.6 Protect Information Through Access Control Lists. Protect all information stored on systems with file system, network share, claims, application, or database specific access control lists.

  2. CWE-284: Improper Access Control. The software does not restrict or incorrectly restricts access to a resource from an unauthorized actor.

  3. CWE-287: Improper Authentication. When an actor claims to have a given identity, the software does not prove or insufficiently proves that the claim is correct.

  4. CWE-306: Missing Authentication for Critical Function. The software does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

  5. CWE-359: Exposure of Private Personal Information to an Unauthorized Actor. The product does not properly prevent a person’s private, personal information from being accessed by actors who either are not explicitly authorized to access the information or do not have the implicit consent of the person about whom the information is collected.

  6. CWE-639: Authorization Bypass Through User-Controlled Key. The system’s authorization functionality does not prevent one user from gaining access to another user’s data or record by modifying the key value identifying the data.

  7. Directive 2002/58/EC (amended by E-privacy Directive 2009/136/EC). Art. 4: Security of processing.(1a) The measures referred to in paragraph 1 shall at least ensure that personal data can be accessed only by authorized personnel for legally authorized purposes.

  8. GDPR. Art. 32: Security of processing.(4) The controller and processor shall take steps to ensure that any natural person acting under the authority of the controller or the processor who has access to personal data does not process them except on instructions from the controller.

  9. GDPR. Recital 6: Ensuring a High Level of Data Protection Despite the Increased Exchange of Data. Technology has transformed both the economy and social life, and should further facilitate the free flow of personal data, while ensuring a high level of the protection of personal data.

  10. NERC CIP-003-8. Attachment 1. Section 3 - 3.1 Permit only necessary inbound and outbound electronic access as determined by the Responsible Entity.

  11. OWASP Top 10 A3:2017-Sensitive Data Exposure. Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.

  12. OWASP Top 10 A5:2017-Broken Access Control. Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users' accounts, view sensitive files, modify other users' data, change access rights, etc.

  13. OWASP-ASVS v4.0.1 V1.2 Authentication Architectural Requirements.(1.2.2) Verify that communications between application components, including APIs, middleware and data layers, are authenticated. Components should have the least necessary privileges needed.

  14. OWASP-ASVS v4.0.1 V1.4 Access Control Architectural Requirements.(1.4.5) Verify that attribute or feature-based access control is used whereby the code checks the user’s authorization for a feature/data item rather than just their role. Permissions should still be allocated using roles.

  15. OWASP-ASVS v4.0.1 V4.2 Operation Level Access Control.(4.2.1) Verify that sensitive data and APIs are protected against direct object attacks targeting creation, reading, updating and deletion of records, such as creating or updating someone else’s record, viewing everyone’s records, or deleting all records.

  16. OWASP-ASVS v4.0.1 V13.2 RESTful Web Service Verification Requirements.(13.2.1) Verify that enabled RESTful HTTP methods are a valid choice for the user or action, such as preventing normal users using DELETE or PUT on protected API or resources.

  17. PCI DSS v3.2.1 - Requirement 1.2.2 Secure and synchronize router configuration files.

  18. PCI DSS v3.2.1 - Requirement 3.6.7 Fully document and implement all key-management processes and procedures for cryptographic keys including prevention of unauthorized substitution of cryptographic keys.

  19. PCI DSS v3.2.1 - Requirement 6.5.8 Address common coding vulnerabilities in software-development processes including improper access control (such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions).

  20. PCI DSS v3.2.1 - Requirement 7.1.1 Define access needs for each role, including system components and data resources that each role needs to access for their job function.

  21. PCI DSS v3.2.1 - Requirement 10.5.1 Limit viewing of audit trails to those with a job-related need.

Service status - Terms of Use - Privacy Policy - Cookie Policy

Copyright © 2021 Fluid Attacks, We hack your software. All rights reserved.