Broken Function Level Authorization Pentesting
Your Users Can't Access Admin Functions. Or Can They?

// BOLA (Broken Object Level Authorization)
// Attack: Access another user's DATA
GET /api/users/1234/profile  // Your profile
GET /api/users/1235/profile  // Someone else's profile - BOLA!

// BFLA (Broken Function Level Authorization)  
// Attack: Access privileged FUNCTIONS
GET /api/users/me/profile    // Normal user function
GET /api/admin/users         // Admin function - BFLA!
DELETE /api/admin/users/1235 // Admin function - BFLA!

// The key difference:
// - BOLA: Same function, different object (user 1234 vs 1235)
// - BFLA: Different function entirely (user endpoint vs admin endpoint)

// Both are devastating:
// - BOLA exposes individual user data
// - BFLA exposes entire system administration

// Attacker is logged in as a regular user
// Session token identifies them as role: "user"

// Step 1: Attacker discovers admin endpoint
// Through: API docs, JS source code, error messages, or just guessing

// Step 2: Attacker makes direct API request
const response = await fetch('/api/admin/users', {
  headers: {
    'Authorization': 'Bearer user_token_here'
  }
});

// Expected behavior: 403 Forbidden
// Actual behavior on vulnerable APIs:
{
  "users": [
    {"id": 1, "email": "admin@company.com", "role": "admin"},
    {"id": 2, "email": "ceo@company.com", "role": "admin"},
    {"id": 3, "email": "user@example.com", "role": "user"},
    // ... entire user database exposed
  ]
}

// Step 3: Attacker escalates further
await fetch('/api/admin/users/2', {
  method: 'DELETE',
  headers: { 'Authorization': 'Bearer user_token_here' }
});
// CEO account deleted by regular user

// Protected: GET request to view users
GET /api/users
Authorization: Bearer admin_token
Result: 200 OK (works for admins)

GET /api/users  
Authorization: Bearer user_token
Result: 403 Forbidden (correctly blocked for regular users)

// Unprotected: DELETE request on same endpoint
DELETE /api/users/1234
Authorization: Bearer user_token
Result: 200 OK - User deleted!

// Why does this happen?
// Common pattern in Express/Node:
app.get('/api/users', requireAdmin, listUsers);    // Protected
app.delete('/api/users/:id', deleteUser);          // OOPS! No middleware

// Or in route definitions:
router.route('/users')
  .get(requireAdmin, listUsers)  // Protected
  .post(createUser);             // Forgot to add requireAdmin!

// The attacker's advantage:
// They test EVERY HTTP method on EVERY endpoint
// Most applications only protect the "obvious" ones

// Vulnerable: Application trusts role from request body
POST /api/users/register
Content-Type: application/json

{
  "email": "attacker@evil.com",
  "password": "securepass123",
  "role": "admin"  // Attacker just made themselves an admin
}

// Server code that causes this:
app.post('/api/users/register', async (req, res) => {
  const { email, password, role } = req.body;
  
  // VULNERABLE: Using role directly from request
  const user = await User.create({ 
    email, 
    password: hash(password), 
    role: role || 'user'  // If they send "admin", they get admin!
  });
  
  res.json({ success: true, user });
});

// Another variant: Role in update endpoints
PUT /api/users/me
{
  "name": "John Doe",
  "role": "admin"  // Privilege escalation via profile update
}

// The Fix: Never trust client-supplied roles
app.post('/api/users/register', async (req, res) => {
  const { email, password } = req.body;
  // role is ALWAYS set server-side, never from request
  const user = await User.create({ 
    email, 
    password: hash(password), 
    role: 'user'  // Hardcoded for registration
  });
});

// Architecture:
// [Client] -> [API Gateway] -> [User Service]
//                           -> [Admin Service]  
//                           -> [Billing Service]

// The Problem: Gateway checks auth, internal services trust gateway

// API Gateway code:
app.use('/api/admin/*', requireAdmin);  // Checks role
app.use('/api/*', authenticate);         // Checks token

// Admin Service code (internal):
app.delete('/users/:id', async (req, res) => {
  // No authorization check - trusts that gateway already verified
  await User.deleteOne({ _id: req.params.id });
  res.json({ success: true });
});

// Attack vector 1: Direct service access
// If attacker discovers internal service URL (10.0.0.5:3001)
// They bypass the gateway entirely
curl -X DELETE http://10.0.0.5:3001/users/admin123

// Attack vector 2: Gateway bypass through misconfiguration
// Attacker finds /internal/admin/users is not protected
GET /internal/admin/users  // Different path, same internal service

// Attack vector 3: Service-to-service impersonation
// Attacker crafts request that looks like inter-service call
POST /api/admin/users
X-Internal-Service: user-service
X-Skip-Auth: true  // Some services honor these headers!

// The Fix: Zero trust architecture
// EVERY service validates authorization independently
// Internal services should not trust external headers

# How attackers discover your admin endpoints:

# 1. JavaScript Source Code Analysis
# Your frontend bundle often contains API paths
grep -r "admin" bundle.js
# Output: axios.get('/api/admin/dashboard')
#         fetch('/api/admin/users')

# 2. API Documentation Leaks
# Swagger/OpenAPI docs often exposed at:
/swagger.json
/api-docs
/openapi.yaml
/.well-known/openapi.json

# 3. Error Messages
GET /api/admi/users
# Response: "Did you mean /api/admin/users?"

# 4. Predictable Naming Patterns
# Common admin endpoint patterns:
/api/admin/*
/api/v1/admin/*
/api/internal/*
/api/management/*
/api/backoffice/*
/admin/api/*
/api/staff/*
/api/superuser/*

# 5. Directory/Endpoint Fuzzing
# Using wordlists designed for admin discovery
ffuf -u https://target.com/api/FUZZ -w admin-wordlist.txt

# 6. GraphQL Introspection
query { __schema { types { name fields { name } } } }
# Returns: AdminMutation, deleteUser, banUser, etc.

# 7. Mobile App Decompilation
# API endpoints hardcoded in mobile apps
strings app.apk | grep -i admin

# Once discovered, attackers simply try accessing them
# If BFLA exists, they succeed immediately