Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > CWE- Individual Dictionary Definition (3.0)  

CWE-285: Improper Authorization

Weakness ID: 285
Abstraction: Class
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.
+ Extended Description

Assuming a user with a given identity, authorization is the process of determining whether that user can access a given resource, based on the user's privileges and any permissions or other access-control specifications that apply to the resource.

When access control checks are not applied consistently - or not at all - users are able to access data or perform actions that they should not be allowed to perform. This can lead to a wide range of problems, including information exposures, denial of service, and arbitrary code execution.

+ Alternate Terms
"AuthZ" is typically used as an abbreviation of "authorization" within the web application security community. It is also distinct from "AuthC," which is an abbreviation of "authentication." The use of "Auth" as an abbreviation is discouraged, since it could be used for either authentication or authorization.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
ChildOfClassClass284Improper Access Control
+ Relevant to the view "Architectural Concepts" (CWE-1008)
MemberOfCategoryCategory1011Authorize Actors
+ Relevant to the view "Development Concepts" (CWE-699)
+ Background Details
An access control list (ACL) represents who/what has permissions to a given object. Different operating systems implement (ACLs) in different ways. In UNIX, there are three types of permissions: read, write, and execute. Users are divided into three classes for file access: owner, group owner, and all other users where each class has a separate set of rights. In Windows NT, there are four basic types of permissions for files: "No access", "Read access", "Change access", and "Full control". Windows NT extends the concept of three types of users in UNIX to include a list of users and groups along with their associated permissions. A user can create an object (file) and assign specified permissions to that object.
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.


REALIZATION: This weakness is caused during implementation of an architectural security tactic.

A developer may introduce authorization weaknesses because of a lack of understanding about the underlying technologies. For example, a developer may assume that attackers cannot modify certain inputs such as headers or cookies.

Architecture and Design

Authorization weaknesses may arise when a single-user application is ported to a multi-user environment.

+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.


Class: Language-Independent (Undetermined Prevalence)


Web Server (Often Prevalent)

Database Server (Often Prevalent)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.


Technical Impact: Read Application Data; Read Files or Directories

An attacker could read sensitive data, either by reading the data directly from a data store that is not properly restricted, or by accessing insufficiently-protected, privileged functionality to read the data.

Technical Impact: Modify Application Data; Modify Files or Directories

An attacker could modify sensitive data, either by writing the data directly to a data store that is not properly restricted, or by accessing insufficiently-protected, privileged functionality to write the data.
Access Control

Technical Impact: Gain Privileges or Assume Identity

An attacker could gain privileges by modifying or reading critical data directly, or by accessing insufficiently-protected, privileged functionality.
+ Likelihood Of Exploit
+ Demonstrative Examples

Example 1

This function runs an arbitrary SQL query on a given database, returning the result of the query.

(bad code)
Example Language: PHP 
function runEmployeeQuery($dbName, $name){
mysql_select_db($dbName,$globalDbHandle) or die("Could not open Database".$dbName);
//Use a prepared statement to avoid CWE-89

$preparedStatement = $globalDbHandle->prepare('SELECT * FROM employees WHERE name = :name');
$preparedStatement->execute(array(':name' => $name));
return $preparedStatement->fetchAll();


$employeeRecord = runEmployeeQuery('EmployeeDB',$_GET['EmployeeName']);

While this code is careful to avoid SQL Injection, the function does not confirm the user sending the query is authorized to do so. An attacker may be able to obtain sensitive employee information from the database.

Example 2

The following program could be part of a bulletin board system that allows users to send private messages to each other. This program intends to authenticate the user before deciding whether a private message should be displayed. Assume that LookupMessageObject() ensures that the $id argument is numeric, constructs a filename based on that id, and reads the message details from that file. Also assume that the program stores all private messages for all users in the same directory.

(bad code)
Example Language: Perl 
sub DisplayPrivateMessage {
my($id) = @_;
my $Message = LookupMessageObject($id);
print "From: " . encodeHTML($Message->{from}) . "<br>\n";
print "Subject: " . encodeHTML($Message->{subject}) . "\n";
print "<hr>\n";
print "Body: " . encodeHTML($Message->{body}) . "\n";


my $q = new CGI;
# For purposes of this example, assume that CWE-309 and
# CWE-523 do not apply.

if (! AuthenticateUser($q->param('username'), $q->param('password'))) {
ExitError("invalid username or password");


my $id = $q->param('id');

While the program properly exits if authentication fails, it does not ensure that the message is addressed to the user. As a result, an authenticated attacker could provide any arbitrary identifier and read private messages that were intended for other users.

One way to avoid this problem would be to ensure that the "to" field in the message object matches the username of the authenticated user.

+ Observed Examples
Web application does not restrict access to admin scripts, allowing authenticated users to reset administrative passwords.
Web application does not restrict access to admin scripts, allowing authenticated users to modify passwords of other users.
Web application stores database file under the web root with insufficient access control (CWE-219), allowing direct request.
Terminal server does not check authorization for guest access.
Database server does not use appropriate privileges for certain sensitive operations.
Gateway uses default "Allow" configuration for its authorization settings.
Chain: product does not properly interpret a configuration option for a system group, allowing users to gain privileges.
Chain: SNMP product does not properly parse a configuration option for which hosts are allowed to connect, allowing unauthorized IP addresses to connect.
System monitoring software allows users to bypass authorization by creating custom forms.
Chain: reliance on client-side security (CWE-602) allows attackers to bypass authorization using a custom client.
Chain: product does not properly handle wildcards in an authorization policy list, allowing unintended access.
Content management system does not check access permissions for private files, allowing others to view those files.
ACL-based protection mechanism treats negative access rights as if they are positive, allowing bypass of intended restrictions.
Product does not check the ACL of a page accessed using an "include" directive, allowing attackers to read unauthorized files.
Default ACL list for a DNS server does not set certain ACLs, allowing unauthorized DNS queries.
Product relies on the X-Forwarded-For HTTP header for authorization, allowing unintended access by spoofing the header.
OS kernel does not check for a certain privilege before setting ACLs for files.
Chain: file-system code performs an incorrect comparison (CWE-697), preventing default ACLs from being properly applied.
Chain: product does not properly check the result of a reverse DNS lookup because of operator precedence (CWE-783), allowing bypass of DNS-based access restrictions.
+ Potential Mitigations

Phase: Architecture and Design

Divide the software 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) 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.

Phase: Architecture and Design

Ensure that you perform access control checks related to your business logic. These checks may be different than the access control checks that you apply 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.

Phase: 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].

Phase: 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.

Phases: 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.
+ Detection Methods

Automated Static Analysis

Automated static analysis is useful for detecting commonly-used idioms for authorization. A tool may be able to analyze related configuration files, such as .htaccess in Apache web servers, or detect the usage of commonly-used authorization libraries.

Generally, automated static analysis tools have difficulty detecting custom authorization schemes. In addition, the software's design may include some functionality that is accessible to any user and does not require an authorization check; an automated technique that detects the absence of authorization may report false positives.

Effectiveness: Limited

Automated Dynamic Analysis

Automated dynamic analysis may find many or all possible interfaces that do not require authorization, but manual analysis is required to determine if the lack of authorization violates business logic

Manual Analysis

This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.

Specifically, manual static analysis is useful for evaluating the correctness of custom authorization mechanisms.

Effectiveness: Moderate

Note: These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules. However, manual efforts might not achieve desired code coverage within limited time constraints.

Manual Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Web Application Scanner
  • Web Services Scanner
  • Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Host Application Interface Scanner
  • Fuzz Tester
  • Framework-based Fuzzer
  • Forced Path Execution
  • Monitored Virtual Environment - run potentially malicious code in sandbox / wrapper / virtual machine, see if it does anything suspicious

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Focused Manual Spotcheck - Focused manual analysis of source
  • Manual Source Code Review (not inspections)

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Formal Methods / Correct-By-Construction
Cost effective for partial coverage:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: High

+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsMissing Access Control
OWASP Top Ten 2007A10CWE More SpecificFailure to Restrict URL Access
OWASP Top Ten 2004A2CWE More SpecificBroken Access Control
Software Fault PatternsSFP35Insecure resource access
+ References
[REF-229] NIST. "Role Based Access Control and Role Based Security". <>.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 4, "Authorization" Page 114; Chapter 6, "Determining Appropriate Access Control" Page 171. 2nd Edition. Microsoft Press. 2002-12-04. <>.
[REF-231] Frank Kim. "Top 25 Series - Rank 5 - Improper Access Control (Authorization)". SANS Software Security Institute. 2010-03-04. <>.
[REF-45] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <>.
[REF-233] Rahul Bhattacharjee. "Authentication using JAAS". <>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Common Vulnerabilities of Authorization", Page 39. 1st Edition. Addison Wesley. 2006.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 11, "ACL Inheritance", Page 649. 1st Edition. Addison Wesley. 2006.
+ Content History
Submission DateSubmitterOrganization
7 Pernicious Kingdoms
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Common_Consequences, Description, Likelihood_of_Exploit, Name, Other_Notes, Potential_Mitigations, References, Relationships
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Description, Related_Attack_Patterns
2009-07-27CWE Content TeamMITRE
updated Relationships
2009-10-29CWE Content TeamMITRE
updated Type
2009-12-28CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Detection_Factors, Modes_of_Introduction, Observed_Examples, Relationships
2010-02-16CWE Content TeamMITRE
updated Alternate_Terms, Detection_Factors, Potential_Mitigations, References, Relationships
2010-04-05CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, References, Relationships
2010-09-27CWE Content TeamMITRE
updated Description
2011-03-24CWE Content TeamMITRE
Changed name and description; clarified difference between "access control" and "authorization."
2011-03-29CWE Content TeamMITRE
updated Background_Details, Demonstrative_Examples, Description, Name, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Observed_Examples, Relationships
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Missing or Inconsistent Access Control
2011-03-29Improper Access Control (Authorization)

More information is available — Please select a different filter.
Page Last Updated: January 18, 2018