paulserban.eu

Writing Edition

Paul Serban

Writing, snippets & book notes

Vol. 2026

May 02, 2020

Missing Function Level Access Control: The Silent Authorization Gap in Modern APIs

Why checking who can log in is never the same as checking who can act - and how attackers exploit the difference

Introduction

Most authorization bugs are not exotic. They don't require a novel cryptographic attack or a fuzzed memory corruption. They require something much simpler: an attacker who notices that a button is hidden in the UI, but the endpoint behind that button is not actually protected. This is the essence of Missing Function Level Access Control (MFLAC) - a vulnerability class where an application correctly authenticates a user but fails to verify that the user is authorized to invoke a specific function, action, or administrative capability.

MFLAC has been a fixture of the OWASP Top 10 for over a decade, appearing under different names as the landscape of web applications shifted from server-rendered pages to REST APIs, GraphQL endpoints, and microservices. What makes it persistently dangerous is that it rarely looks like a security bug during development. Code reviews focus on business logic. QA tests the "happy path" through the UI. Nobody clicks a button that doesn't exist - but an attacker doesn't need a button. They need an HTTP client and a guess.

Context: Where This Vulnerability Comes From

To understand MFLAC, it helps to separate two concepts that are frequently conflated in engineering conversations: authentication and authorization. Authentication answers "who are you?" Authorization answers "what are you allowed to do?" A huge share of real-world security incidents trace back to systems that solved the first problem thoroughly - OAuth2, SSO, MFA, session management - while treating the second as an afterthought, often implemented ad hoc at the UI layer rather than enforced consistently at the point where the action actually happens.

This gap is amplified by how modern front-end frameworks work. A single-page application built in React, Vue, or Angular typically renders different views based on a user's role: an "Admin" menu item appears only if user.role === 'admin', a "Delete Organization" button is hidden unless the user owns the resource. This is good UX, but it is not security - it is presentation logic running entirely on a client the attacker controls. If the corresponding server-side endpoint, say DELETE /api/organizations/:id, does not independently re-verify the caller's authorization, then hiding the button accomplished nothing except reducing the chance that a legitimate user stumbles into an action they shouldn't take. It does nothing to stop someone who reads the network tab, inspects the API contract, or simply guesses the route pattern from a public API scan.

The problem compounds in service-oriented architectures. When a monolith splinters into a dozen microservices, each with its own set of endpoints, the responsibility for enforcing access control often gets distributed unevenly. One team builds robust middleware for their service; another assumes "the gateway already checked that." Without a shared, enforced convention, some fraction of endpoints inevitably end up unauthenticated for specific verbs, unauthorized for specific roles, or simply forgotten during a refactor. The larger and more distributed the system, the more surface area exists for exactly one endpoint to be missed.

What Missing Function Level Access Control Actually Is

Formally, MFLAC occurs when an application fails to verify, at the point of executing a privileged function, that the authenticated user holds the role, permission, or ownership relationship required to perform that function. It is closely related to two entries in the Common Weakness Enumeration: CWE-862 (Missing Authorization) and CWE-285 (Improper Authorization). In the OWASP API Security Top 10 (2023 edition), this issue is explicitly captured as API5:2023 - Broken Function Level Authorization, and it sits alongside the related but distinct API1:2023 (Broken Object Level Authorization), which concerns access to specific records rather than specific functions.

The distinction between object-level and function-level authorization is worth internalizing precisely because they are often bundled together carelessly. Object-level access control asks: "Can this user access this particular resource?" - for example, can user 42 read invoice 917, which belongs to a different tenant? Function-level access control asks a different question: "Can this user invoke this capability at all, regardless of which object it targets?" - for example, can a regular employee call the endpoint that promotes users to administrator, irrespective of whose account is being promoted. A system can correctly enforce one and completely fail at the other. Many real breaches involve function-level gaps specifically because engineers built thorough ownership checks (does this record belong to this tenant?) while never asking whether the function itself should be reachable by this role in the first place.

How Attackers Discover and Exploit It

The exploitation pattern for MFLAC is almost always the same, and it does not require sophisticated tooling. An attacker with a low-privilege account - often a free-tier user, a normal employee, or even an unauthenticated guest - inspects legitimate traffic using browser developer tools or an intercepting proxy such as Burp Suite or OWASP ZAP. They catalog the API endpoints that a privileged user's client calls, even if those exact calls never appear in their own session, because JavaScript bundles frequently ship the full set of route definitions and API client methods regardless of the current user's role. From there, they replay a privileged request - say, POST /api/admin/users/:id/roles - using their own, lower-privileged session token.

If the server-side handler checks only that a valid session exists, and not that the session belongs to a user with the admin role, the request succeeds. This is often discovered by simple parameter and path enumeration: trying /api/v1/users/export, /api/v1/admin/dashboard, or /internal/health and observing which return 200 instead of 401/403. Automated scanners and even generic web crawlers can surface these endpoints from JavaScript source maps, OpenAPI/Swagger documents left exposed in production, or predictable REST naming conventions. This is why "security through obscurity" - hiding an endpoint's existence rather than gating its use - consistently fails: obscurity buys minutes, not defense.

A second, subtler exploitation path involves HTTP verb tampering. A developer might correctly protect GET /api/reports/:id with an ownership check but forget that the same route also accepts a DELETE verb, added later for a bulk-cleanup feature, which reuses the routing but not the authorization middleware. Because many web frameworks allow multiple HTTP methods to share a route definition, and because authorization middleware is sometimes attached per-route rather than per-verb, this creates exactly the kind of inconsistency that a determined tester finds by simply trying every verb against every known path.

A third pattern shows up in GraphQL and RPC-style APIs, where a single endpoint (often just /graphql) exposes many distinct "functions" as fields or mutations rather than as separate URLs. Because there is no visible route-per-function, teams sometimes assume that authentication at the transport layer is sufficient, and they neglect to place authorization checks inside each resolver. An attacker who obtains the schema - frequently exposed via introspection queries in non-production-hardened GraphQL servers - can enumerate every mutation, including administrative ones, and simply attempt to call them directly.

Why This Vulnerability Persists Despite Being Well Known

It is worth asking why MFLAC remains common when it has been documented in security literature and standards for well over a decade. Part of the answer is architectural: authorization is a cross-cutting concern, and cross-cutting concerns are notoriously easy to implement inconsistently across a codebase unless there is a single, enforced mechanism. Unlike authentication, which is usually centralized in one login flow and one middleware layer, authorization decisions are scattered across every controller, resolver, and command handler in the system. Each one is a separate opportunity to forget the check, copy-paste a stale check from a different context, or assume upstream layers already handled it.

Another part of the answer is organizational. Front-end and back-end work is frequently split across different teams or even different companies (in the case of outsourced development), and role visibility in the UI is often treated as the primary deliverable of an "access control" ticket. A product manager writes an acceptance criterion like "only admins should see the delete button," QA verifies that non-admin users don't see the button, and the ticket is closed - without anyone writing an acceptance criterion for the API layer itself. The vulnerability isn't introduced through malice or incompetence; it emerges from an incomplete definition of "done."

Finally, MFLAC is dangerous precisely because it produces no errors during normal operation. A missing authorization check doesn't crash the application, doesn't show up in application performance monitoring, and doesn't trigger obvious log anomalies unless someone has specifically instrumented authorization decisions. The system behaves exactly as designed for every legitimate user. The gap is invisible until someone with malicious intent - or a security researcher - goes looking for it specifically.

When This Vulnerability Is Most Likely to Appear

Certain moments in a system's lifecycle disproportionately introduce MFLAC. The first is rapid feature growth, particularly when new administrative or privileged capabilities are bolted onto an existing API surface under time pressure. A team building a customer support "impersonate user" feature, for example, may correctly gate the UI entry point behind a support-role check while forgetting that the underlying /api/sessions/impersonate endpoint needs its own explicit authorization, independent of the UI.

The second is architectural migration. When a team moves from a monolith to microservices, or from server-rendered views to a client-rendered SPA backed by a REST or GraphQL API, authorization logic that used to live implicitly in server-side view rendering (where an unauthorized user simply never received the HTML for a restricted page) must be re-implemented explicitly at the API boundary. This re-implementation is easy to get wrong, especially under the assumption that "the old system already handled this" when in fact the old system handled it through a mechanism - page rendering - that no longer exists in the new architecture.

The third is the addition of new roles or permission tiers to a system that was originally built with a simple binary model (user vs. admin). Introducing a third role, such as "manager" or "auditor," often requires revisiting every function-level check in the codebase, and teams frequently update only the checks they remember exist, missing endpoints added by other contributors or in other services. Any refactor that touches the permission model should be treated as a full authorization audit, not a targeted patch, precisely because the blast radius of a forgotten check is invisible until exploited.

Implementation Patterns That Prevent It

The most durable fix for MFLAC is to centralize authorization decisions so that no individual route handler can "forget" to call them. Below is a Node.js/Express example showing the difference between an implicit, easily-missed pattern and an explicit, centrally enforced one.

// authorization.ts - centralized policy enforcement
type Role = 'user' | 'manager' | 'admin';

interface AuthenticatedRequest extends Express.Request {
  user: { id: string; role: Role };
}

// A declarative policy map, reviewed as a single artifact rather than
// scattered across dozens of files.
const functionPolicies: Record<string, Role[]> = {
  'users:promote':        ['admin'],
  'users:export':         ['admin', 'manager'],
  'reports:delete':       ['admin'],
  'reports:read':         ['admin', 'manager', 'user'],
  'billing:refund':       ['admin'],
};

export function requirePermission(action: keyof typeof functionPolicies) {
  return (req: AuthenticatedRequest, res: Express.Response, next: Function) => {
    const allowedRoles = functionPolicies[action];
    if (!allowedRoles) {
      // Fail closed: an action with no defined policy is denied,
      // not silently allowed.
      return res.status(403).json({ error: 'No policy defined for this action' });
    }
    if (!allowedRoles.includes(req.user.role)) {
      return res.status(403).json({ error: 'Insufficient permissions' });
    }
    next();
  };
}

// routes/admin.ts - every privileged route references the shared policy,
// so the authorization check travels with the action, not with the route file.
router.post('/api/users/:id/promote', requirePermission('users:promote'), promoteUserHandler);
router.delete('/api/reports/:id', requirePermission('reports:delete'), deleteReportHandler);
router.post('/api/billing/:id/refund', requirePermission('billing:refund'), refundHandler);

This pattern has two properties that matter more than the specific syntax. First, it fails closed: an action string with no entry in functionPolicies is rejected rather than allowed, which means a forgotten policy definition produces a loud 403 during testing rather than a silent bypass in production. Second, it decouples the what (which roles can perform this action) from the where (which route or resolver triggers it), so the same policy map can be reused by a REST controller, a GraphQL resolver, and a background job handler that all ultimately call promoteUserHandler.

The same principle applies outside the request-handling layer. In Python, a common approach is to enforce function-level checks with decorators that wrap the business logic itself, rather than relying solely on route-level middleware, so that the check travels with the function even if it is called from an internal script, a Celery task, or a new endpoint added later.

# auth_decorators.py
from functools import wraps
from flask import g, abort

PERMISSION_MAP = {
    "promote_user": {"admin"},
    "delete_report": {"admin"},
    "issue_refund": {"admin"},
    "export_users": {"admin", "manager"},
}

def require_permission(action: str):
    def decorator(func):
        @wraps(func)
        def wrapper(*args, **kwargs):
            allowed_roles = PERMISSION_MAP.get(action)
            if allowed_roles is None:
                abort(403, description=f"No policy defined for '{action}'")
            if g.current_user.role not in allowed_roles:
                abort(403, description="Insufficient permissions")
            return func(*args, **kwargs)
        return wrapper
    return decorator


@require_permission("issue_refund")
def issue_refund(order_id: str, amount: float):
    # Business logic only runs if the decorator's check passes,
    # regardless of which route, script, or job invoked this function.
    ...

Placing the check on the function itself, rather than exclusively on the HTTP route, closes the verb-tampering and internal-reuse gaps described earlier: if issue_refund is later called from a new admin CLI tool or a scheduled batch job, the permission check still executes, because it is attached to the function's identity rather than to one specific entry point.

Trade-offs and Common Pitfalls

Centralizing authorization is not free of trade-offs, and engineers should go into it with realistic expectations. The first cost is the need for a single, well-maintained source of truth for the permission map. If that map lives in application code, every new privileged action requires a code change and a deployment, which can slow down teams that need to adjust permissions frequently. Some organizations address this by externalizing policy into a dedicated authorization service or policy engine - such as Open Policy Agent (OPA) with its Rego policy language, or attribute-based access control (ABAC) systems - but this introduces its own operational complexity: a new network dependency, a new place for latency to creep in, and a new system that itself needs to be authenticated and monitored.

A second pitfall is over-trusting role-based checks when the real authorization requirement is relationship-based. Function-level access control answers "can this role call this function," but many real systems need "can this specific user act on this specific resource, given their relationship to it" - a manager may be allowed to approve expense reports, but only for their own direct reports, not for the entire company. Teams sometimes solve this by inflating the role model into dozens of narrow roles ("manager-of-team-a," "manager-of-team-b"), which becomes unmanageable, rather than combining function-level checks with object-level ownership checks, which properly separates the two concerns and lets each be implemented and audited independently.

A third pitfall is inconsistent enforcement across transport mechanisms. A team may diligently protect REST endpoints with the pattern above, then add a WebSocket channel, a batch import job, or an internal gRPC service for service-to-service calls, and forget that these new surfaces need the same policy checks. Internal services in particular are often assumed to be "trusted" simply because they're not internet-facing, which is a dangerous assumption in any environment where lateral movement by a compromised service or a malicious insider is a realistic threat. Zero-trust architectural principles - verifying every call regardless of network origin - exist specifically to counter this assumption.

Finally, teams sometimes over-correct by adding so many granular permission checks that the system becomes difficult to reason about, with permission logic duplicated slightly differently across services, or with contradictory policies that nobody can confidently audit. Authorization logic should be auditable in the same way a database schema is auditable: a reviewer should be able to open one artifact and understand the entire permission model, rather than needing to trace logic across dozens of files to determine who can do what.

Best Practices for Preventing Missing Function Level Access Control

The single highest-leverage practice is to default to deny. Every function that performs a privileged action should require an explicit, positive authorization grant before executing; the absence of an explicit check should never be interpreted as implicit permission. This principle, sometimes phrased as "fail closed, not open," should be enforced structurally - for example, through the fail-closed behavior shown in the code samples above - rather than relying on individual engineers to remember it during a busy sprint.

Beyond that default, several practices compound to meaningfully reduce risk. Authorization checks should be enforced server-side for every request, with client-side role checks treated purely as a UX convenience, never as a security control. Automated tests should specifically attempt privileged actions using low-privilege and unauthenticated tokens - a "negative test suite" that verifies the API rejects forbidden actions is just as important as tests that verify legitimate actions succeed, and it should run in CI, not just during periodic manual penetration tests. API documentation and route inventories should be treated as security artifacts: teams should be able to enumerate every function-level endpoint in the system and confirm each one has an associated, reviewed policy, which is far easier when authorization is centralized as in the earlier examples than when it's scattered per-handler. Finally, regular access-control-focused code reviews and periodic third-party penetration testing - explicitly scoped to test both object-level and function-level authorization, per the OWASP API Security Top 10 methodology - remain the most reliable way to catch the gaps that automated tooling and internal review miss.

Key Takeaways

Analogies and Mental Models

A useful mental model for MFLAC is a hotel with keycard doors. Hiding the "Staff Only" sign on a door (the UI's hidden button) does nothing if the door itself opens with any guest's keycard. Real security requires the door's lock - the server-side function - to check the specific card presented against a list of authorized cards, every single time, regardless of whether a sign was posted. A well-run hotel doesn't rely on guests being too polite to try the staff door; it relies on the lock actually working.

Another way to think about it: authentication is the wristband you get at the entrance of a venue, proving you paid for admission. Authorization is the separate check at the VIP lounge door, verifying that your specific wristband color grants access to that specific room. A venue that only checks "does this person have a wristband" at every internal door - without checking wristband color - will eventually have general-admission guests wandering into the VIP lounge, the backstage area, and the cash office, simply because nobody at those specific doors asked the right question.

The 80/20 Insight

If a team can only invest in one structural change to reduce MFLAC risk, it should be this: build a single, centralized authorization layer that every privileged function must pass through, and make that layer fail closed by default. This one architectural decision - rather than a long checklist of individual fixes - addresses the root cause common to nearly every real-world instance of this vulnerability: authorization logic scattered across the codebase with no single point of enforcement or audit. Everything else discussed in this article, from negative testing to policy engines to role modeling, is valuable, but it is secondary to establishing that single choke point. Teams that get this one decision right early tend to avoid an entire category of incidents; teams that postpone it tend to discover the gap through an incident report rather than a code review.

Conclusion

Missing Function Level Access Control persists not because it is technically difficult to prevent, but because it is organizationally easy to overlook. It hides in the gap between "the UI looks secure" and "the API is secure," and it thrives in systems where authorization logic is implemented ad hoc, function by function, rather than as a single reviewable policy. The fix is neither exotic nor expensive: centralize authorization decisions, default to deny, verify every privileged action server-side regardless of what the client believes about its own role, and test for the absence of access as rigorously as for its presence.

None of this requires abandoning existing architecture or adopting a specific vendor's policy engine - OPA and dedicated ABAC systems are useful tools, but the underlying discipline matters more than the tool chosen to implement it. What matters is that the question "is this caller authorized to invoke this specific function?" gets asked, explicitly and consistently, at the one place in the system where it actually counts: the server, at the moment the action is about to happen. Every system that has suffered a real MFLAC-driven breach had, somewhere, a function that simply never asked that question.

References

A quick flashcard preview - one example of each question type in this post. This is a demo of what you'll find in the full quiz app.

Flashcard preview - 1 / 9Multiple Choice

multiple choice - intermediate - auto-graded

A regular employee discovers they can call an endpoint that promotes any user to administrator, even though the UI never shows them this option. Which category of authorization failure does this best illustrate?

Choose an answer