CWE-862: Missing Authorization — When Authentication Exists but Access Control Fails

by admintech2 Comments 3 min read

Many organizations invest heavily in authentication and still suffer critical breaches because they neglect the equally important question of what an authenticated user is allowed to do. Missing Authorization vulnerabilities occur when applications verify identity but fail to enforce whether that identity should be permitted to perform a requested action.

CWE-862 occurs when software does not perform an authorization check when an actor attempts to access a resource or perform an action.

In practical terms:

The application knows who you are—but never checks whether you should be allowed.

This article breaks down how missing authorization flaws occur, why developers still introduce them, modern exploitation techniques, framework-specific mitigations, and secure authorization design patterns.

What Is Missing Authorization?

Missing Authorization happens when an application exposes functionality or data without validating the current user’s permissions.

Unsafe example:

@app.route("/admin/delete-user/<id>")
def delete_user(id):
    perform_delete(id)

If the route is accessible to any authenticated user, authorization is missing.

Authentication verifies identity.

Authorization verifies permission.

Confusing the two creates systemic access control failures.

How Missing Authorization Actually Works

The root issue is absent or incomplete permission checks before sensitive actions.

Attack Flow

  1. User authenticates legitimately
  2. User discovers privileged endpoint/resource
  3. Application verifies session only
  4. No role/ownership/permission check occurs
  5. Unauthorized access or action succeeds

Visual: Missing Authorization Data Flow

1. User Logs In Authenticated 2. Access Admin/API Sensitive Endpoint 3. No AuthZ Check Session Only 4. Result Privilege Abuse

Why Developers Still Get Authorization Wrong

Authentication/Authorization Confusion

Teams implement login and assume the hard part is done.

Frontend-Only Enforcement

Developers hide buttons/UI elements but fail to enforce server-side checks.

Decentralized Permission Logic

Authorization rules scattered across controllers/services create gaps.

Rapid API Expansion

New endpoints appear faster than security review.

Internal/Admin Endpoint Assumptions

“Users won’t know this exists” is not access control.

Modern Exploitation Techniques

Forced Browsing

Attacker manually requests hidden/admin endpoints.

Role Parameter Manipulation

Changing client-controlled role values:

{ "role": "admin" }

API Enumeration

Discovering undocumented endpoints via:

  • Mobile apps
  • JavaScript bundles
  • Swagger/OpenAPI docs
  • Traffic interception

Chained Access Control Abuse

Combining weak authorization with IDOR/BOLA flaws.

Visual: Authorization Failure Exploitation Chain

Missing Authorization Privilege Escalation Sensitive Data Access Admin Function Abuse Full Account/System Impact

Framework-Specific Mitigations

Centralized Authorization Middleware

Apply authorization before business logic:

@app.route("/admin")
@require_role("admin")
def admin_panel():
    ...

Policy-Based Authorization

Use declarative policy engines/rules.

Examples:

  • ASP.NET Authorization Policies
  • Spring Security Expressions
  • Django Permissions
  • OPA / Cedar / Zanzibar-like models

Resource Ownership Checks

Validate object-level access:

if invoice.owner_id != current_user.id:
    deny()

Secure Coding Examples

Unsafe

if (user.loggedIn) {
    deleteUser(id);
}

Safer

if (user.role === "admin") {
    deleteUser(id);
}

Better

Centralize rules:

authorize(user, "delete_user", targetUser)

Avoid duplicating ad hoc role checks.

Defense in Depth

Deny by Default

Require explicit allow rules.

Log Authorization Failures

Detect probing and abuse attempts.

Test Negative Cases

Security tests should verify unauthorized access fails.

Review Hidden/Internal Endpoints

Treat undocumented routes as public unless protected.

Final Thoughts

Missing Authorization remains pervasive because authentication is visible and authorization is often invisible until it fails.

It persists because:

  • Teams conflate login with access control
  • UI restrictions are mistaken for security
  • Permission logic fragments over time
  • APIs multiply faster than reviews

The core lesson is simple:

Authentication answers “Who are you?” Authorization answers “What are you allowed to do?” You need both.

HAL9000 on Skynet’s CWE-862 Recommendations