Database access control errors occur when:

1. Data enters a program from an untrusted source.

2. The data is used to specify a data value in an LDAP query.
Example 1: The employee ID of the current authenticated user is automatically submitted with each request by the client-side interface. The following code properly validates an employee name using an allow list before using it to construct an LDAP query. This validation prevents LDAP injection vulnerabilities, but may still leave the code vulnerable.

static string AllowlistVerify(string name) {
    Regex pattern = new Regex(@"^[a-zA-Z\-\.']+$");
    if (pattern.IsMatch(name)) {
        return name;
    }
    return null;
}

...
string verifiedName = AllowlistVerify(managerName.Text.trim());
if(verifiedName != null) {
    DirectorySearcher src = new DirectorySearcher("(manager=" + verifiedName + ")");
    src.SearchRoot = de;
    src.SearchScope = SearchScope.Subtree;

    foreach(SearchResult res in src.FindAll()) {
        ...
    }
}

The problem is that the developer has failed to consider what would happen if an attacker provides alternate values of empName. Although the interface automatically submits the employee ID of the current user, an attacker could submit an alternative value as part of a malicious request. Because the code in this example executes the query under an anonymous bind, it will return the directory entry for any valid employee ID, regardless of the identity of the current authenticated user.

Database access control errors occur when:

1. Data enters a program from an untrusted source.

2. The data is used to specify a data value in an LDAP query.
Example 1: The following code uses an allow list to validate an employee name read from a socket before using it to construct an LDAP query. This validation prevents LDAP injection vulnerabilities, but may still leave the code vulnerable.

char* allowlist_verify(char* name) {
    const char *error;
    int errOffset;
    char* regex = "^[a-zA-Z\\-\\.']+$";
    pcre* re = pcre_compile(regex, 0, &err, &errOffset, NULL);
    int rc = pcre_exec(re, NULL, name, strlen(name), 0, 0, NULL, 0);
    if (rc == 1)
        return name;
    return NULL;
}
...
fgets(managerName, sizeof(managerName), socket);
char* verified_name = allowlist_verify(managerName);
if(verified_name != NULL) {
    snprintf(filter, sizeof(filter), "(manager=%s)", verified_name);
    if ( ( rc = ldap_search_ext_s( ld, FIND_DN, LDAP_SCOPE_BASE,
            filter, NULL, 0, NULL, NULL, LDAP_NO_LIMIT,
            LDAP_NO_LIMIT, &result ) ) == LDAP_SUCCESS ) {
    ...
    }
}

The problem is that the developer has failed to consider what would happen if an attacker provides alternate values of username. Because the code in this example executes the query under an anonymous bind, it will return the directory entry for any valid employee ID, regardless of the identity of the current authenticated user.

Privilege escalation issues occur when an attacker can bypass access control checks by submitting carefully crafted request parameter values. Applications that fail to sufficiently validate user supplied values that influence access control decisions expose themselves to authorization bypass threats. This can lead to attackers gaining access to sensitive resources or ability to remotely execute malicious arbitrary commands.
Example: The following code demonstrates authentication of administrative accounts

$admintest = 0;
if(isset($admin)) {
  if(!IsSet($mainfile)) { include("mainfile.php3"); }
  $admin = base64_decode($admin);
  $admin = explode(":", $admin);
  $aid = "$admin[0]";
  $pwd = "$admin[1]"; 

  dbconnect();
  $result=mysql_query("select pwd from authors where aid='$aid'");
  if(!$result) {
    echo "Selection from database failed!";
    exit;
  } else {
    list($pass)=mysql_fetch_row($result); 

    if($pass == $pwd) {
      $admintest = 1;
    }
  }
} 

The example code above uses the $admin value for access control checks. Any variables, either from cookies or forms (GET/POST) will be automatically made global to the script by PHP. An attacker can therefore manipulate the value of the admin variable by passing the desired value using a request parameter. If $pwd (an element of that "scrambled" $admin) does not match the value that corresponds to the fetched row, the false authentication ($admintest = 0) is returned, otherwise we'll be able to access any function in admin.php3.
To bypass the authorization checks, the attacker needs to ensure that $pass == $pwd. The $pass value returned from mysql_fetch_row() could be anything, or could be FALSE if there are no more rows. The attacker in this case can exploit the mismatch in the datatype to equalize $pwd (string-type) and $pass (logical-type). The expression "if($pass == $pwd)" only compares values, NOT the type. As a result, setting $pwd = "" (null) will be EQUAL (though not identical) to the given FALSE value of $pass.
To force the value of $pass to FALSE, the attacker only needs to set $aid to a string value that does not exist in the authors database. This will result in the mysql_query() call to return TRUE and the mysql_fetch_row() call to return FALSE.
Thus the attacker can fully bypass the authorization checks using the following values:

$aid = "blabla"; $pwd = "";

and send the result of base64_encode("$aid:$pwd") in the admin request parameter.