Authorization

Introduction to Authorization

Authorization is the process of determining what an authenticated user,
device, application or service is allowed to access or perform.

Authentication establishes identity. Authorization determines what that
identity is permitted to do.

A secure application should not assume that every authenticated user is
allowed to access every page, record, API endpoint or administrative
function.

1. Authentication vs Authorization

Both controls are important, but they solve different security problems.

2. Why Authorization Matters

Imagine a school management system with the following users:

• Student
• Instructor
• Administrator

All three users may successfully authenticate. However, they should not
necessarily have the same permissions.

Authorization ensures that these boundaries are enforced.

3. Users, Roles and Permissions

A useful way to understand authorization is to separate three concepts.

• User: The authenticated identity.
• Role: A collection or classification of permissions.
• Permission: A specific action or resource access right.

For example, a role called Instructor might contain
permissions such as:

• View assigned students.
• Create lessons.
• Grade assignments.

A role called Student might contain:

• View enrolled courses.
• Submit assignments.
• View personal grades.

4. Principle of Least Privilege

The principle of least privilege means that an identity should receive only
the permissions required to perform its legitimate responsibilities.

For example, a student account normally does not need permission to:

• Delete other users.
• Change server configuration.
• Modify system-wide security settings.
• Access another student’s private records.

Least privilege reduces the potential impact of compromised accounts,
mistakes and unauthorized actions.

5. Deny by Default

A secure authorization design commonly starts with the principle:

Deny access unless permission has been explicitly granted.

This is often called deny-by-default.

Instead of attempting to predict every action that should be forbidden,
developers define the actions that are legitimately permitted.

6. Server-Side Authorization

Authorization must be enforced on the server.

A button hidden with JavaScript does not provide real security.

For example, hiding an administrator button from a normal user does not
prevent that user from manually requesting the administrator endpoint.

The server must independently verify the user’s permissions before
performing the requested action.

7. Role-Based Access Control

Role-Based Access Control, commonly called RBAC, assigns permissions to
roles rather than directly assigning every permission to every user.

Example:

Student
    ├── view_course
    ├── submit_assignment
    └── view_own_grade

Instructor
    ├── view_course
    ├── create_lesson
    ├── grade_assignment
    └── view_student_progress

Administrator
    ├── manage_users
    ├── manage_courses
    ├── manage_settings
    └── manage_system

RBAC can simplify permission management in organizations where job
responsibilities are clearly defined.

8. Attribute-Based Access Control

Attribute-Based Access Control, or ABAC, evaluates attributes when deciding
whether access should be permitted.

Attributes can include:

• User role.
• Department.
• Resource type.
• Resource owner.
• Location.
• Device security state.
• Time.
• Requested action.

For example:

Allow access when:

user.department = "Finance"
AND
resource.type = "FinanceReport"
AND
user.role = "Manager"

The actual rules should be defined according to the application’s
requirements and security model.

9. Access Control Lists

An Access Control List, or ACL, is a collection of rules that identifies
which identities or groups can perform specific actions on a resource.

ACLs are common in operating systems, file systems, databases, networks
and applications.

A file might conceptually have rules such as:

• Owner: read and write.
• Finance group: read.
• Everyone else: no access.

10. Object-Level Authorization

Object-level authorization controls access to individual records or objects.

Consider a learning platform containing:

/student/profile/101
/student/profile/102
/student/profile/103

A logged-in student should not automatically be able to access every
student profile merely because the URL contains a different numeric ID.

The server should verify whether the authenticated user is actually
authorized to access the requested object.

11. IDOR and BOLA Concepts

Two related authorization weaknesses are commonly discussed in web security:

• IDOR: Insecure Direct Object Reference.
• BOLA: Broken Object Level Authorization.

The general problem occurs when an application exposes an object identifier
but fails to verify whether the current user is allowed to access that
specific object.

The security solution is not simply hiding object IDs. The server should
perform an authorization check for every sensitive object access.

12. Horizontal Access Control

Horizontal authorization concerns access between users with similar
privilege levels.

For example, Student A and Student B may both have the Student role.

Student A should normally be able to access their own records but not
Student B’s private records.

This is an object-level authorization problem when the application fails
to enforce ownership correctly.

13. Vertical Access Control

Vertical authorization concerns access between users with different
privilege levels.

For example:

Student
   ↓
Instructor
   ↓
Administrator

A student should not automatically gain instructor or administrator
permissions simply because they can reach a particular URL.

14. Function-Level Authorization

Applications must protect sensitive functions as well as individual
records.

Examples include:

• Delete user.
• Change system settings.
• Publish a course.
• Approve an account.
• Export sensitive information.
• Change another user’s role.

Each sensitive operation should have an appropriate server-side permission
check.

15. API Authorization

APIs require authorization just like normal web pages.

An API endpoint should verify:

• Who is making the request.
• Whether the identity is authenticated.
• Whether the identity has the required permission.
• Whether the requested object belongs to or is accessible by that identity.

An API should not assume that possession of a valid token grants unlimited
access.

16. Multi-Tenant Applications

In a multi-tenant application, different organizations or customer groups
may share the same software platform.

For example:

Company A
    ├── Users
    ├── Courses
    └── Reports

Company B
    ├── Users
    ├── Courses
    └── Reports

A user belonging to Company A should not automatically be able to access
Company B’s records.

Tenant isolation must therefore be part of the authorization model.

17. Privilege Escalation

Privilege escalation refers to gaining permissions beyond those normally
assigned to an identity.

It can occur because of:

• Weak authorization logic.
• Incorrect role configuration.
• Exposed administrative functions.
• Insecure object access.
• Improper permission inheritance.
• Application design mistakes.

Developers should test authorization boundaries carefully in authorized
environments.

18. Authorization and Least Privilege

Authorization and least privilege work together.

A secure system should provide:

• Only the permissions required.
• Only for the appropriate users.
• Only for the appropriate resources.
• Only for the appropriate actions.
• Only for as long as necessary.

19. Separation of Duties

Separation of duties prevents a single identity from controlling every
stage of a sensitive process.

For example, an organization may separate:

• Request approval.
• Financial authorization.
• Payment processing.

This reduces the risk of one compromised or misused account controlling an
entire sensitive workflow.

20. Administrative Accounts

Administrative accounts should receive special protection because they can
often modify security-sensitive resources.

Good practices include:

• Use strong authentication.
• Use MFA.
• Limit administrator accounts.
• Use separate administrative identities where appropriate.
• Review administrative permissions regularly.
• Monitor privileged activity.
• Avoid using administrative privileges for ordinary tasks.

21. Authorization Checks in PHP

The following example demonstrates a simple server-side authorization
function using synthetic data.

<?php

$user = array(
    'role' => 'instructor',
);

$required_role = 'instructor';

if (
    isset( $user['role'] )
    &&
    $user['role'] === $required_role
) {

    echo 'Access permitted.';

} else {

    echo 'Access denied.';
}

A production application normally needs a more complete permission model
than comparing a single role string.

22. Permission-Based Authorization

A permission-based model can be more precise than checking only a role.

<?php

$user_permissions = array(
    'view_course',
    'submit_assignment',
);

$required_permission = 'view_course';

if (
    in_array(
        $required_permission,
        $user_permissions,
        true
    )
) {

    echo 'Permission granted.';

} else {

    echo 'Permission denied.';
}

This approach allows applications to define specific capabilities.

23. WordPress Authorization

WordPress uses roles and capabilities to help control what authenticated
users can do.

Developers should use capability checks when protecting administrative or
sensitive functionality.

For example:

<?php

if ( current_user_can( 'manage_options' ) ) {

    echo 'Access permitted.';

} else {

    echo 'Access denied.';
}

The capability should match the sensitivity of the operation. Developers
should avoid granting broad administrative capabilities when a narrower
capability is sufficient.

24. WordPress Nonces and Authorization

WordPress nonces are useful for helping protect actions against unwanted
requests, but they are not a replacement for authorization.

A secure WordPress action may therefore require both:

1. A valid nonce.
2. An appropriate capability check.

The capability check answers whether the user is allowed to perform the
action. The nonce helps verify that the request was generated in an
appropriate context.

25. Authorization for Database Records

Applications that retrieve database records should include authorization
logic before returning sensitive information.

Conceptually:

1. Authenticate the user.
2. Identify the requested record.
3. Determine the user's relationship to the record.
4. Check the required permission.
5. Return the record only if authorization succeeds.

Developers should avoid assuming that knowing a database ID is sufficient
permission to access the associated record.

26. Authorization Logging

Authorization events can provide useful security evidence.

Applications may record events such as:

• Access denied.
• Administrative actions.
• Permission changes.
• Role changes.
• Sensitive record access.
• Account privilege changes.

Logs should avoid unnecessarily storing sensitive personal information or
secrets.

27. Access Reviews

Permissions should not remain unchanged forever.

Organizations can periodically review:

• Users.
• Roles.
• Administrative accounts.
• Service accounts.
• Inactive accounts.
• Former employees.
• Temporary permissions.

Regular access reviews help identify permissions that are no longer needed.

28. Joiner, Mover and Leaver Controls

Authorization should follow the user’s lifecycle.

Joiner

When a person joins an organization, they receive the minimum permissions
required for their role.

Mover

When a person changes department or responsibility, permissions should be
reviewed and adjusted.

Leaver

When a person leaves an organization, unnecessary access should be removed
promptly according to organizational procedures.

29. Common Authorization Mistakes

• Checking permissions only in the user interface.
• Trusting role information supplied by the browser.
• Failing to check object ownership.
• Using predictable URLs as if they were security controls.
• Giving every authenticated user administrator permissions.
• Failing to protect API endpoints.
• Forgetting to protect background or AJAX requests.
• Failing to review old permissions.
• Using broad administrative capabilities unnecessarily.
• Assuming authentication automatically means authorization.

30. Secure Authorization Design

A secure authorization system should follow several principles.

• Enforce authorization on the server.
• Deny by default.
• Use least privilege.
• Keep permissions specific.
• Check object ownership.
• Protect every sensitive endpoint.
• Review administrative privileges.
• Log important authorization events.
• Remove unnecessary permissions.
• Test authorization boundaries.

31. Authorization Security Scenario

Consider a Dwallnet LMS containing student records.

A student is authenticated successfully and requests another student’s
record by supplying that student’s record identifier.

The application should not simply check whether the requester is logged in.
It should also determine whether the authenticated student is authorized to
view the requested record.

A secure flow would be:

User authenticated
        ↓
Identify requested student record
        ↓
Check ownership or permitted relationship
        ↓
Check required capability
        ↓
Allow or deny request

32. Practical Cybersecurity Lab

Create a small local authorization system using synthetic users.

Create three roles:

• Student
• Instructor
• Administrator

Create several permissions such as:

• view_course
• submit_assignment
• grade_assignment
• manage_users
• manage_courses

Then create test cases to verify that each role receives only the intended
permissions.

The lab should be performed only on a system you own or have explicit
permission to test.

33. Synthetic Authorization Test

<?php

$user = array(
    'role' => 'student',
);

$permissions = array(
    'student' => array(
        'view_course',
        'submit_assignment',
    ),

    'instructor' => array(
        'view_course',
        'submit_assignment',
        'grade_assignment',
    ),

    'administrator' => array(
        'view_course',
        'manage_users',
        'manage_courses',
    ),
);

$requested_permission = 'manage_users';

$role = $user['role'];

if (
    isset( $permissions[ $role ] )
    &&
    in_array(
        $requested_permission,
        $permissions[ $role ],
        true
    )
) {

    echo 'Authorization granted.';

} else {

    echo 'Authorization denied.';
}

This is a simple educational example. Production systems should use a
carefully designed authorization model, secure data storage and server-side
enforcement.

34. Review Checklist

• Is the user authenticated?
• Is the requested resource identified correctly?
• Is the user allowed to access that resource?
• Is the requested action permitted?
• Is object ownership checked?
• Is tenant isolation enforced?
• Are administrative functions protected?
• Are API endpoints protected?
• Are authorization checks performed on the server?
• Are permissions reviewed periodically?

35. Key Takeaways

• Authorization determines what an identity is allowed to do.
• Authentication and authorization are different security controls.
• Authorization must be enforced server-side.
• Least privilege limits unnecessary access.
• Deny-by-default is a strong authorization design principle.
• RBAC assigns permissions through roles.
• ABAC can use multiple attributes when making access decisions.
• Object-level authorization protects individual records.
• IDOR and BOLA involve failures to enforce object-level authorization.
• Horizontal authorization protects users from accessing other users’ resources.
• Vertical authorization protects higher-privilege functions.
• API endpoints require authorization checks.
• Multi-tenant applications must isolate tenant data.
• WordPress developers should use appropriate capability checks.
• Nonces do not replace authorization.
• Permissions should be reviewed throughout the user lifecycle.

36. Review Questions

1. What is authorization?
2. How is authorization different from authentication?
3. What is the principle of least privilege?
4. What does deny-by-default mean?
5. What is RBAC?
6. What is ABAC?
7. What is an ACL?
8. What is object-level authorization?
9. What are IDOR and BOLA?
10. What is horizontal access control?
11. What is vertical access control?
12. Why must authorization be enforced on the server?
13. Why should APIs perform authorization checks?
14. What is tenant isolation?
15. Why should administrative permissions be reviewed regularly?
16. Are WordPress nonces a replacement for capability checks?

Conclusion

Authorization is one of the most important controls in a secure web
application. A user being successfully authenticated does not mean that
the user should have unrestricted access.

Developers must enforce permissions at the server, protect individual
objects and sensitive functions, apply least privilege, isolate tenants,
review administrative access and test authorization boundaries.

The next lesson will examine Input Validation and how
applications safely handle data supplied by users and external systems.