Exploiting Broken Function Level Authorization

---
name: exploiting-broken-function-level-authorization
description: Use when tests APIs for Broken Function Level Authorization (BFLA) vulnerabilities
  where regular users can invoke administrative functions or access privileged API
  endpoints by directly calling them. The tester identifies admin and privileged endpoints,
  then attempts to access them with regular user credentials by manipulating HTTP
  methods, URL paths, and request parameters. Maps to OWASP API5:2023 Broken Function
  Level Authorization.
domain: cybersecurity
tags:
- api-security
- owasp
- authorization
- bfla
- privilege-escalation
- access-control
subdomain: api-security
version: 1.0.0
author: oyi77
license: Apache-2.0
nist_csf:
- PR.PS-01
- ID.RA-01
- PR.DS-10
- DE.CM-01
category: cybersecurity
---

# Exploiting Broken Function Level Authorization

## Overview

Cybersecurity skill for exploiting broken function level authorization. Follows industry best practices and security standards.

## When to Use
**Trigger phrases:**
- "exploiting broken function level authorization"
- "Tests APIs for Broken Function Level Authorization (BFLA) vulnerabilities where "


- Testing whether regular users can access administrative API endpoints by direct URL access
- Assessing APIs for vertical privilege escalation where users can invoke functions above their role
- Evaluating if API gateways and middleware consistently enforce function-level access controls
- Testing role-based access control (RBAC) implementation across all API endpoints and HTTP methods
- Validating that API documentation does not expose admin endpoint paths that lack authorization

**Do not use** without written authorization. BFLA testing involves attempting to execute administrative functions with unauthorized credentials.


## When NOT to Use

- When you lack proper authorization for testing
- For production systems without change management
- When the task requires legal or compliance expertise beyond technical scope


## Prerequisites

- Written authorization specifying target API and administrative functions in scope
- Test accounts at multiple privilege levels: regular user, moderator, admin, super-admin
- API documentation (OpenAPI/Swagger spec) that may list admin endpoints
- Burp Suite Professional for request interception and manipulation
- Python 3.10+ with `requests` library
- Knowledge of common admin endpoint naming conventions

## Workflow

```python
# Example: IOC detection
import re

IOC_PATTERNS = {
    "ip": r"\b(?:\d{1,3}\.){3}\d{1,3}\b",
    "domain": r"\b[a-z0-9-]+\.[a-z]{2,}\b",
    "hash_md5": r"\b[a-f0-9]{32}\b",
    "hash_sha256": r"\b[a-f0-9]{64}\b",
}

def extract_iocs(text: str) -> dict:
    return {k: re.findall(v, text) for k, v in IOC_PATTERNS.items()}
```

1. **Reconnaissance** — Gather information about the target related to broken function level authorization. Identify attack surface.
2. **Vulnerability Identification** — Enumerate potential broken function level authorization weaknesses using automated and manual techniques.
3. **Exploit Development/Selection** — Choose or develop exploits targeting identified broken function level authorization vulnerabilities.
4. **Execution** — Execute the broken function level authorization test in a controlled manner with proper authorization.
5. **Post-Exploitation** — Document the impact and extent of successful exploitation.
6. **Reporting** — Write detailed findings with reproduction steps, impact assessment, and remediation guidance.

## Tools

- **Vulnerability Scanner** — Automated weakness identification
- **Exploitation Framework** — Controlled exploitation testing
- **Reporting Tool** — Findings documentation and tracking


## Process

1. **Reconnaissance** — Gather target information, identify attack surface, enumerate services
1. **Analysis/Exploitation** — Execute the technique, analyze results, document findings
1. **Reporting** — Document IOCs, write findings, provide remediation recommendations

## Verification

- [ ] All broken function level authorization procedures executed completely and documented
- [ ] Findings validated against multiple data sources
- [ ] False positives identified and filtered
- [ ] Results documented with evidence and timestamps
- [ ] Recommendations provided with risk-based prioritization

## Anti-Rationalization Table

| Rationalization | Reality |
|---|---|
| "We are too small to be targeted" | Automated attacks target everyone. Size does not matter. |
| "Security slows us down" | A breach slows you down 100x more. Build security in from the start. |
| "We will fix it after launch" | Vulnerabilities in production are exploited within hours. Fix before deploy. |