CWE Glossary

CWE is a trademark of the MITRE Corporation.

Stay in touch

Application security insights and invitations to exclusive events in your inbox


Your data will stay confidential Private and Confidential

Improper Access Control [CWE-284]

This weakness describes a failure in the AAA security model.

Created: September 11, 2012
Latest Update: August 6, 2015

Table of Content

  1. Description
  2. Potential impact
  3. Attack patterns
  4. Affected software
  5. Severity and CVSS Scoring
  6. Mitigations
  7. References
  8. Latest Related Security Advisories

1. Description

Access control is a security process that controls usage of specific resources within a predefined criteria and is a part of the AAA (Authentication, Authorization, Accounting) security model. All modern systems use certain access control models to manage their security. Access control models can be grouped in three main classes: Mandatory Access Control (MAC), Discretionary Access Control (DAC), and Role Based Access Control (RBAC).

1.1 Mandatory Access Control (MAC)

MAC is an access control model implemented in many modern operating systems such as SELinux (since kernel 2.6), FreeBSD (since 5.0), SUSE Linux, Ubuntu, Microsoft Windows (starting with Vista), etc. In MAC a security policy administrator controls the overall security policy. Users do not have the ability to override the defined policy set and e.g. grant access to otherwise restricted objects. This policy is based on mandated regulations determined by a central authority.

1.2 Discretionary Access Control (DAC)

The DAC access control model is based on identity of the requestor and defined access rules that determine allowed actions. Access decisions are typically based on provided credentials and are subject to manipulation within specified bounds. In most DAC model implementations the owner of the object can modify its permissions and transfer ownership to other subjects.

1.3 Role Based Access Control (RBAC)

Role-based policies control access to objects depending on the roles that user have within the system and on rules that define access permissions for users in the given role.

Discretionary and role-based policies usually contain an administrative policy that defines an administrative account for access control management.

The Improper Access Control weakness describes a case where software fails to restrict access to an object properly. A malicious user can compromise security of the software and perform certain unauthorized actions by gaining elevated privileges, reading otherwise restricted information, executing commands, bypassing implemented security mechanisms, etc.

Two major behaviors can potentially introduce the access control weaknesses:

  • Specification: Some permissions, privileges or ownerships, which are initially intended for certain users or processes, can indeed be applied to other users or processes (e.g. placing a file with secured key into a word-readable directory, or assigning capabilities of a privileged account to a guest user).
  • Enforcement: the security mechanism contains errors that prevent proper enforcement of the specified access control requirements (e.g. allowing the user to specify his own access controls or allowing incorrect access control lists to produce insecure settings). This problem occurs within the application that does not correctly enforce or inherits the intended security policy.

The following PHP code can be used as an example of the improper access control weakness:


  1. <?php
  2. // Improper Access Control [CWE-284] vulnerable code example
  3. // (c) HTB Research
  4. define ("ACCESS_DENIED",false);
  5. if ($_SERVER["REQUEST_METHOD"]=="GET"):
  6.   ACCESS_DENIED=true;
  7.   if(CUser->IsAuthorized()):
  8.     ACCESS_DENIED=false;
  9.   else:
  10.     ACCESS_DENIED=true;
  11.   endif;
  12. endif;
  13. if (ACCESS_DENIED):
  14.   echo "You don't have permission to access this file.";
  15. else:
  16.   ShowPrivilegedContent();
  17. endif;
  18. ?>

In the above code, the ACCESS_DENIED constant is erroneously declared as false. An attacker might be able to send a HTTP POST request to the script, bypass the authorization checks intended for the HTTP GET method, and gain access to output of the ShowPrivilegedContent() function.

2. Potential impact

This weakness allows an attacker to bypass intended security restrictions and perform a variety of actions depending on the source of error and functionality of the application. An attacker might be able to perform certain actions by gaining elevated privileges, reading otherwise restricted information, executing commands, bypassing implemented security mechanisms, etc.

3. Attack patterns

There is only one CAPEC pattern that is related to this weakness:


This weakness is not described as an attack technique in WASC Threat Classification database.

4. Affected software

Any software intended to handle access controls is potentially vulnerable to this weakness.

5. Severity and CVSS Scoring

This vulnerability could be scored differently depending on application's design, its functionality and potential security impact. In case an attacker gets full control over the application or can read, modify and delete data, it should be scored as:
7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) - High severity.

If an attacker can execute arbitrary system commands or inject arbitrary code, this weakness should be scored as:
10 (AV:N/AC:L/Au:N/C:C/I:C/A:C) – Critical severity.


We use CVSSv2 scoring system in our HTB Security Advisories to calculate the risk of the discovered vulnerabilities. Not all of the vulnerabilities are scored in strict accordance to FIRST recommendations. Our CVSSv2 scores are based on our long internal experience in software auditing and penetration testing, taking into consideration a lot of practical nuances and details. Therefore, sometimes they may differ from those ones that are recommended by FIRST.

6. Mitigations

Improper access control weaknesses usually result in logic errors. Developers must carefully manage settings and handling of privileges as well as pay attention to security zones within the application. They should also integrate mechanisms that control privilege separation functionality and think about creating architecture that relies on the least privilege principle.

7. References

  1. CWE-284: Improper Access Control [cwe.mitre.org]
  2. Insufficient Authorization [projects.webappsec.org]
  3. Mandatory access control [wikipedia.org]
  4. Mandatory Access Control [lindqvist.awardspace.info]
  5. Access Control: Policies, Models, and Mechanisms [spdp.dti.unimi.it]
  6. Access Control Model (Windows) [msdn.microsoft.com]

8. Latest HTB Security Advisories with CWE-284


Copyright Disclaimer: Any above-mentioned content can be copied and used for non-commercial purposes only if proper credit to High-Tech Bridge is given.

↑ Back to Top
High-Tech Bridge on Facebook High-Tech Bridge on Twitter High-Tech Bridge on LinkedIn High-Tech Bridge RSS Feeds Send by Email
Share