Function Level Access Control Failure

Description

Function Level Access Control Failure (FLAC), classified under CWE-285 — Improper Authorization, occurs when an application exposes server-side functions or API endpoints without enforcing proper authorization checks on each invocation. The developer may have hidden administrative UI elements from regular users, restricted navigation in the front-end, or implemented role-based UI rendering — but failed to add corresponding authorization enforcement on the back-end handlers that those functions invoke.

This is a pervasive and underestimated vulnerability. Modern applications expose dozens or hundreds of API endpoints. Developers typically implement authentication middleware globally, but authorization logic — which endpoints are accessible to which roles — is often implemented inconsistently, added later, or simply forgotten for "internal" endpoints. Mobile API clients exacerbate this: their APIs are often less hardened than web-facing APIs because they were designed under the assumption that only the mobile app would interact with them.

FLAC sits firmly within A01:2021 — Broken Access Control. The HTTP verb matters as well: many applications implement GET authorization correctly but forget to restrict POST, PUT, DELETE, or PATCH to the same endpoint. An attacker simply changes the method.

How It Works

A regular user browses the application and sees only their own account settings. An administrative panel exists at /admin — but there are no links to it from the user's session. The developer relied on UI hiding as the security control.

The attacker uses Burp Suite to discover the admin API endpoints by analyzing the JavaScript bundle:

// Extracted from bundle.js
const API = {
  getUsers:    () => fetch('/api/v1/admin/users'),
  deleteUser:  (id) => fetch(`/api/v1/admin/users/${id}`, { method: 'DELETE' }),
  exportData:  () => fetch('/api/v1/admin/export'),
};

With a regular user's session token, the attacker sends:

GET /api/v1/admin/users HTTP/1.1
Host: app.example.com
Authorization: Bearer <regular_user_token>

The server responds with 200 OK and a full list of all user accounts, including names, emails, hashed passwords, and account metadata. The authorization check was never implemented on the backend — only the front-end hid the link.

HTTP method switching is a common FLAC variant. The GET /api/v1/users/{id} endpoint correctly checks that the requester is the owner or an admin. But DELETE /api/v1/users/{id} was added later without the same check:

DELETE /api/v1/users/victim_id HTTP/1.1
Authorization: Bearer <attacker_regular_user_token>

The server deletes the target account without authorization.

Predictable admin path discovery is another vector. Endpoints like /api/v1/admin/*, /api/internal/*, /management/*, and /actuator/* (Spring Boot) are commonly present and commonly unprotected. Spring Boot Actuator endpoints (/actuator/env, /actuator/heapdump, /actuator/shutdown) have caused major incidents when exposed without authentication.

Impact

• Unauthorized data access — administrative user lists, logs, financial reports, and PII exposed to regular users.
• Privilege escalation — invoking admin functions to modify roles, reset passwords, or unlock accounts.
• Mass data deletion or modification — unprotected DELETE and PUT endpoints allow bulk data destruction.
• System configuration changes — admin endpoints for feature flags, system settings, or infrastructure configuration are modified.
• Credential theft — export or backup endpoints deliver full user databases to unauthorized callers.
• Service disruption — shutdown or restart endpoints (e.g., Spring Boot /actuator/shutdown) can terminate the application.

Detection

1. Extract all API endpoints from the JavaScript bundle and mobile app — use grep -r "api/v" on decompiled mobile binaries and beautified JS. Build a complete map of every endpoint.
2. Test every endpoint with a lower-privileged token — systematically replay each administrative or privileged API call (discovered in step 1) using a regular user's session token. A successful response confirms FLAC.
3. Test HTTP method variations — for every endpoint, try GET, POST, PUT, PATCH, DELETE, and OPTIONS. Authorization is sometimes implemented per-method rather than per-resource.
4. Enumerate common admin paths — test /admin, /api/admin, /api/v1/admin, /management, /actuator, /console, /internal, and /api/internal with low-privileged sessions.
5. Test Spring Boot Actuator endpoints if the application is Java-based: /actuator/health, /actuator/env, /actuator/beans, /actuator/heapdump, /actuator/logfile, /actuator/mappings.
6. Review mobile app API clients — decompile APK with jadx or IPA with class-dump and trace all API calls. Test each discovered endpoint independently from the mobile context.

Remediation

Implement authorization in middleware for every route. Apply role and permission checks at the routing layer, not in individual controller methods. This ensures no endpoint can be added without inheriting the authorization requirement:

// Express.js middleware approach
router.use("/api/v1/admin", authenticate, requireRole("admin"));
router.get("/api/v1/admin/users", getUsers);
router.delete("/api/v1/admin/users/:id", deleteUser);

Adopt a default-deny posture. All endpoints should require explicit authorization grants. An endpoint with no authorization annotation should fail closed — return 401 or 403 — rather than succeed.

Secure Spring Boot Actuator. In application.properties, restrict the management port, require authentication, and expose only health and info endpoints by default:

management.endpoints.web.exposure.include=health,info
management.endpoint.health.show-details=never
spring.security.user.password=<strong_password>

Apply the same authorization standards to mobile APIs. Mobile API endpoints must have identical authorization controls to web API endpoints. "The mobile app won't call this" is not an authorization control.

Conduct function-level access control testing as a dedicated test phase. Enumerate the complete API surface and explicitly test each endpoint against each role in your role matrix.