API BFLA, Broken Function Level Authorization (OWASP API5)

Purpose

Test whether regular (or partially privileged) users can invoke administrative API functions that should be restricted to higher roles.

Preconditions

• At least one low-privilege session (plus admin session when available, to build the expected-behavior baseline)
• Admin endpoint/verb inventory from OpenAPI specs, JS bundles, error messages, or documentation
• No assumption that the UI hides a function, the backend must be tested directly

Attack Surface Signals

• Paths containing admin/manage/internal/system/console/backoffice/ops
• Documentation or JS referencing privileged operations not linked in the UI
• Role-conditional features in frontend code (the API behind them)
• Management verbs on normal resources: PUT /users/{id}/role, POST /users/{id}/disable, DELETE /audit/logs

Methodology

Step 1: Build the Admin Inventory

for path in admin manage management internal system console backoffice ops \
  admin/users admin/settings admin/config admin/logs admin/reports admin/billing; do
  for method in GET POST PUT PATCH DELETE; do
    code=$(curl -sk -o /dev/null -w "%{http_code}" -X $method \
      -H "Authorization: Bearer LOW_PRIV_TOKEN" "https://TARGET/api/v1/$path")
    echo "$method /$path -> $code"
  done
done

Treat any non-401/403 outcome as a CANDIDATE, never as a finding by itself.

Step 2: Role-Differential Matrix

admin legitimate request on function F   → 200 + privileged effect (baseline)
same request with lower-privilege session  → candidate if NOT 401/403
same request anonymous                    → candidate if NOT 401/403
verify effect with an authorized read     → finding only if the privileged
                                            state actually changed / data returned

Use authz_matrix when multiple roles exist; test moderator/support tiers too, not just user-vs-admin, partial-role gaps are common.