12 API Security Assessment

Mission Overview

Welcome to Lab 12 — API Security Assessment.

In Lab 11, you assessed how the application server communicates with backend and remote destinations.

Now you will focus on the application’s API security surface.

Modern web applications increasingly depend on APIs for:

authentication
account management
mobile applications
dashboards
internal services
data retrieval
workflow automation
third-party integrations

An API may appear secure in the browser while exposing weaknesses when requests are sent directly.

That is why API testing must validate security independently of the UI.

Mission Goal: Assess the authorized training API for authentication, authorization, object ownership, method handling, schema validation, sensitive data exposure, pagination, filtering, rate controls, versioning, error handling, and state-changing operations.

Mission Information

Item	Details
Difficulty	Intermediate
Estimated Time	150–180 minutes
Primary Skill	API Security Assessment
Secondary Skill	API Authorization & Data Exposure Analysis
Environment	GoHackersCloud Web Pentesting Lab
Testing Mode	Controlled API Assessment
Primary Outcome	API Security Assessment Report
Safety Level	Authorized Training API Only

Learning Objectives

By completing this lab, you will be able to:

build an API endpoint inventory
identify API versions
identify authentication mechanisms
assess unauthenticated access
validate API authorization
test object-level authorization
compare multiple authorized identities
assess function-level authorization
validate HTTP methods
assess JSON/schema validation
identify excessive data exposure
assess sensitive-field handling
evaluate pagination and filtering
identify mass-assignment risks conceptually
evaluate rate controls
assess deprecated API versions
assess state-changing API functions
review error handling
distinguish API observations from validated findings
document positive controls
create professional API security evidence

Core Methodology

Use:

Inventory → Authenticate → Baseline → Compare Identities → Validate Schema → Validate Object Access → Assess Data Exposure → Assess Rate Controls → Evidence → Report

Expanded:

API Discovery
      │
      ▼
Endpoint Inventory
      │
      ▼
Authentication Baseline
      │
      ▼
Role / Identity Mapping
      │
      ▼
Request / Response Baselines
      │
      ▼
Object-Level Authorization
      │
      ▼
Function-Level Authorization
      │
      ▼
Schema & Input Validation
      │
      ▼
Sensitive Data Review
      │
      ▼
Method & Workflow Assessment
      │
      ▼
Rate / Abuse Controls
      │
      ▼
Version & Legacy Review
      │
      ▼
Evidence
      │
      ▼
Report

The core principle is:

The API must enforce security at the server boundary regardless of what the browser, mobile application, or client interface chooses to show.

Part 1 — Confirm Scope

Record:

ASSESSMENT ID:
GHC-WEB-LAB12-001

APPLICATION:

API BASE URL:

AUTHORIZED:
Yes

TEST ACCOUNTS:

AUTHORIZED ROLES:

AUTHORIZED API VERSIONS:

EXCLUDED ENDPOINTS:

TEST WINDOW:

Use only the dedicated training API.

Part 2 — Create the Lab Workspace

Create:

Web-Pentesting-Labs/
└── Lab-12/
    ├── 01-Scope/
    ├── 02-API-Inventory/
    ├── 03-Versions/
    ├── 04-Authentication/
    ├── 05-Baselines/
    ├── 06-Authorization/
    ├── 07-Objects/
    ├── 08-Methods/
    ├── 09-Schemas/
    ├── 10-Data-Exposure/
    ├── 11-Pagination/
    ├── 12-Rate-Controls/
    ├── 13-Errors/
    ├── 14-Legacy/
    ├── 15-Positive-Controls/
    ├── 16-Evidence/
    ├── 17-Findings/
    └── 18-Report/

Part 3 — Build the API Inventory

Use earlier endpoint discovery work from Labs 02–04.

Common API patterns include:

/api/users

/api/profile

/api/orders

/api/documents

/api/admin

/api/v1/

api/v2/

Create:

API ID	Endpoint	Method	Purpose
API-001	`/api/v1/profile`	GET	User profile
API-002	`/api/v1/orders`	GET	User orders
API-003	`/api/v1/orders/{id}`	GET	Order details
API-004	`/api/v1/profile`	PATCH	Update profile

Part 4 — Create the Master API Register

For each endpoint record:

API ID:

VERSION:

ENDPOINT:

METHOD:

AUTHENTICATION REQUIRED:

EXPECTED ROLE:

OBJECT TYPE:

STATE CHANGING:
Yes / No

EXPECTED RESPONSE TYPE:

SENSITIVE DATA:
Yes / No

Part 5 — Identify API Versions

Common patterns:

/api/v1/

/api/v2/

/v1/api/

or version information in headers.

Create:

Version	Status	Notes
v1	Active / Legacy
v2	Active

Part 6 — Understand Version Risk

Older API versions may:

remain accessible
enforce weaker authorization
expose additional fields
lack newer validation
retain deprecated functionality

But:

Old API Version ≠ Vulnerability Automatically

You must validate an actual security difference.

Part 7 — Identify Authentication Mechanisms

API authentication may use:

Session Cookie

Bearer Token

API Key

OAuth Access Token

Signed Request

Other

Record:

API AUTHENTICATION PROFILE

Mechanism:

Token Location:

Cookie / Header:

Authentication Endpoint:

Token Lifetime:
Known / Unknown

Refresh Mechanism:
Yes / No / Unknown

Part 8 — Protect API Credentials

Treat API tokens like passwords.

Do not include complete reusable tokens in ordinary notes or reports.

Use:

Authorization: Bearer [REDACTED]

where appropriate.

Part 9 — Establish an Authenticated API Baseline

Using User A:

GET /api/v1/profile

Record:

AUTHENTICATED API BASELINE

API ID:

Authenticated As:

Role:

Method:

Endpoint:

Status:

Response Type:

Expected User Data:
Yes / No

Sensitive Fields:

Evidence:

Part 10 — Establish User B Baseline

Repeat using User B.

Create:

Attribute	User A	User B
User ID
Role
Profile endpoint
Object ID

This allows controlled authorization comparison.

Part 11 — Assess Unauthenticated API Access

Remove authentication and request a protected endpoint.

Record:

UNAUTHENTICATED API TEST

Endpoint:

Expected:
Authentication Required

Observed Status:

Data Returned:
Yes / No

Sensitive Data Returned:
Yes / No

Result:

Part 12 — Interpret 401 and 403 Carefully

Typical semantics:

401
Authentication required / invalid

403
Authenticated but not authorized

But application behavior varies.

The real question is whether unauthorized data or functionality is exposed.

Part 13 — Build the Authentication Matrix

Endpoint	Anonymous	User	Admin
`/api/profile`	Deny	Own	Policy
`/api/orders`	Deny	Own	Policy
`/api/admin/users`	Deny	Deny	Allow

Part 14 — Identify Object References

Common fields include:

id

user_id

account_id

order_id

document_id

invoice_id

They may appear in:

URL paths
query parameters
JSON bodies

Part 15 — Create the API Object Register

Object	Owner	Endpoint	Identifier
Order A	User A	`/api/orders/1001`	1001
Order B	User B	`/api/orders/2001`	2001

Part 16 — Assess Object-Level Authorization

Using User A’s authenticated API context, request User B’s training object.

Record:

OBJECT AUTHORIZATION TEST

Authenticated As:
User A

Requested Object:
User B Object

Endpoint:

Status:

Object Returned:
Yes / No

Owner Verified:
Yes / No

Authorization Enforced:
Yes / No

Part 17 — Understand BOLA

Broken Object Level Authorization may occur when:

Authenticated User A
        │
        ▼
Requests Object B
        │
        ▼
Server Fails Ownership Check
        │
        ▼
Object B Returned / Modified

This is often analogous to IDOR in API environments.

Object ID Present ≠ BOLA

The authorization failure must be validated.

Part 18 — Build the Object Authorization Matrix

User	Object	Expected
A	A	Allow
A	B	Deny
B	B	Allow
B	A	Deny

Part 19 — Assess Object-Level Write Authorization

For an explicitly authorized, reversible lab object, compare:

PATCH /api/orders/{id}

or another safe update function.

Use only harmless test fields.

Record:

OBJECT WRITE TEST

Authenticated As:

Target Owner:

Object:

Safe Field:

Original Value:

Requested Value:

Modified:
Yes / No

Restored:
Yes / No

Part 20 — Assess Function-Level Authorization

Some API endpoints expose privileged functions rather than user-owned objects.

Examples:

/api/admin/users

/api/admin/reports

/api/users/{id}/role

Using a standard lab user, verify whether server-side role enforcement prevents access.

Part 21 — Understand BFLA

Broken Function Level Authorization may arise when a lower-privileged user can invoke a privileged API operation.

Conceptually:

Standard User
      │
      ▼
Privileged API Function
      │
      ▼
Server Fails Role Check
      │
      ▼
Administrative Function Executes

Part 22 — Create the Function Authorization Register

Function	Expected Role	Standard User	Admin
User list	Admin
Role update	Admin
System report	Admin

Part 23 — Assess HTTP Methods

An endpoint may support:

GET
POST
PUT
PATCH
DELETE

Record the legitimate methods observed during normal application behavior.

Do not blindly spray every possible HTTP verb.

Part 24 — Create the Method Register

Endpoint	Expected Method	Other Observed Methods
`/api/profile`	GET/PATCH
`/api/orders`	GET

Part 25 — Assess Method-Level Authorization

Sometimes:

GET

is protected correctly while:

PATCH

is not.

Assess read and write functions separately.

Read Authorization ≠ Write Authorization

Part 26 — Assess Unsupported Methods

Using only low-impact requests, determine whether clearly unsupported methods are:

Rejected

Ignored

Mapped unexpectedly

Possible responses include:

405 Method Not Allowed

Do not assume a different response is automatically a vulnerability.

Part 27 — Capture Request Schemas

For JSON APIs, record the expected schema.

Example:

{
  "name": "lab-user",
  "department": "training"
}

Create:

SCHEMA PROFILE

Endpoint:

Required Fields:

Optional Fields:

Types:

Allowed Values:

Unknown Fields:
Rejected / Ignored / Unknown

Part 28 — Assess Missing Required Fields

Use harmless variations.

Record:

Test	Result
Required field omitted
Required field empty
Null field

Part 29 — Assess Type Validation

Example expected:

{
  "quantity": 2
}

Benign variation:

{
  "quantity": "training"
}

Record whether the server:

rejects
normalizes
errors
unexpectedly processes

Part 30 — Assess Unknown Fields

Add a harmless unexpected training field, such as:

{
  "name": "lab-user",
  "ghc_test_marker": "LAB12"
}

Observe whether the server:

Rejects

Ignores

Returns

Stores

Do not use privilege-related fields unless the lab explicitly authorizes that test.

Part 31 — Understand Mass Assignment Conceptually

Mass assignment can become a problem when an application automatically binds client-supplied fields to sensitive server-side object properties.

Conceptually:

Client JSON
    │
    ▼
Automatic Object Binding
    │
    ▼
Sensitive Field Modified

The risk depends on whether sensitive fields are writable by unauthorized users.

Part 32 — Assess Writable Fields Safely

Where the lab explicitly exposes safe role/profile fields, record:

WRITABLE FIELD PROFILE

Field:

User Controlled:

Expected Writable:
Yes / No

Server Accepts:
Yes / No

Security Sensitive:
Yes / No

Do not escalate your privileges outside the intentionally designed training workflow.

Part 33 — Assess Excessive Data Exposure

Compare what the API returns with what the client actually needs.

Example response:

{
  "id": 42,
  "name": "lab-user",
  "email": "student@example.test",
  "internal_status": "training",
  "debug_reference": "..."
}

Ask:

Does the API expose fields that should not be available to this caller?

Part 34 — Create the Response Field Register

Field	Needed by Client	Sensitive	Appropriate
name	Yes	No	Yes
email	Yes	Moderate	Policy
internal flag	No	Potential
admin metadata	No	Yes

Part 35 — Distinguish Large Responses from Excessive Exposure

An API returning many fields is not automatically insecure.

You must consider:

caller authorization
business purpose
field sensitivity
client need

Part 36 — Assess Cross-User Data Exposure

Compare User A and User B responses.

Check for accidentally returned:

Other account information

Internal identifiers

Admin-only fields

Unrelated objects

Organization-wide records

Use only known lab data.

Part 37 — Assess Collection Endpoints

Examples:

GET /api/orders

GET /api/users

GET /api/documents

Ask whether the response is scoped correctly.

For a standard user:

Own records only?

or:

All records?

Part 38 — Create the Collection Scope Register

Endpoint	Caller	Expected Scope	Observed
`/api/orders`	User A	User A orders
`/api/documents`	User A	User A docs

Part 39 — Assess Pagination

Common parameters include:

page

limit

offset

cursor

Record:

PAGINATION PROFILE

Endpoint:

Default Limit:

Maximum Observed:

Pagination Method:

Oversized Benign Limit:
Rejected / Capped / Accepted

Avoid resource-intensive values.

Part 40 — Assess Filtering

Examples:

status

owner

date

category

The question is whether filters can cause the API to return data outside the caller’s authorization.

A filter should refine authorized data, not redefine authorization.

Part 41 — Build the Filter Authorization Register

Filter	Caller	Expected Result	Observed
Own status filter	User A	Own data
Owner filter	User A	Still own data only

Part 42 — Assess Sorting

Sorting parameters may include:

sort

order

sort_by

Use only documented or naturally observed values.

Focus on:

input validation
errors
data-scope consistency

Part 43 — Assess Search Endpoints

API search may return more information than the UI.

Compare:

UI search

with:

API search response

Record whether the API reveals additional fields or objects.

Part 44 — Assess Error Handling

Capture benign invalid requests.

Potentially sensitive errors may reveal:

stack traces
framework versions
database details
internal paths
object model names

Create:

API ERROR PROFILE

Endpoint:

Test:

Status:

Error Code:

User Message:

Technical Details:

Sensitive:
Yes / No

Part 45 — Prefer Structured Errors

A well-designed API might return something like:

{
  "error": "invalid_request",
  "message": "Invalid input."
}

rather than internal implementation detail.

Part 46 — Assess Rate Controls

Use a small, controlled request window.

Do not perform high-volume abuse.

Record:

RATE CONTROL PROFILE

Endpoint:

Small Test Window:

Response Status:

Rate Header:

Retry Information:

Throttling Observed:
Yes / No

Conclusion:

Part 47 — Rate Controls May Differ by Function

Higher-risk functions can include:

Login

Password Reset

OTP

Search

Export

Report Generation

Expensive API Queries

Do not test all of them at high volume.

Part 48 — Distinguish Rate Limit from Business Quota

An API may enforce:

security rate limiting

or:

product/account quota

These are not necessarily the same control.

Part 49 — Assess Response Headers

Review:

Content-Type

Cache-Control

WWW-Authenticate

RateLimit / Retry-After style headers

CORS-related headers

Interpret them in context.

Part 50 — Assess Sensitive API Caching

For sensitive responses, record:

CACHE PROFILE

Endpoint:

Sensitive Data:
Yes / No

Cache-Control:

Shared Caching Risk:
Observed / Not Observed / Unknown

Do not assume every cached response is vulnerable.

Part 51 — Assess CORS Conceptually

Cross-Origin Resource Sharing controls which browser origins can access API responses.

Review naturally observed CORS behavior.

Record:

CORS PROFILE

Access-Control-Allow-Origin:

Credentials Allowed:

Allowed Methods:

Allowed Headers:

Expected Frontend Origin:

Do not target unrelated origins.

Part 52 — Distinguish CORS from Authorization

Always remember:

CORS is a browser security mechanism. It does not replace API authentication or authorization.

An API must remain secure even when called directly outside a browser.

Part 53 — Assess State-Changing Operations

Identify:

POST

PUT

PATCH

DELETE

and record whether:

authentication is required
authorization is checked
input is validated
object ownership is enforced
the response confirms the intended change

Part 54 — Create the State Change Register

Operation	Role	Object
Update profile	User	Own
Cancel order	User	Own
Delete document	User	Own

Part 55 — Restore Lab State

For every reversible state-changing test:

ORIGINAL STATE:

TEST CHANGE:

RESTORED:
Yes / No

RESTORATION EVIDENCE:

Part 56 — Assess DELETE Behavior

Only delete dedicated training objects.

Determine whether:

ownership is enforced
object disappears
direct access stops
audit/state behavior matches the lab design

Part 57 — Assess API Version Differences

For the same authorized function across two available training versions:

/api/v1/profile

/api/v2/profile

compare:

authentication
authorization
fields
validation
errors

Part 58 — Create the Version Comparison Matrix

Security Area	v1	v2
Authentication
Authorization
Returned fields
Input validation
Error handling

Part 59 — Assess Deprecated Endpoints

If a version is explicitly documented as deprecated, determine:

Still reachable?

Still authenticated?

Same authorization?

Same data minimization?

Do not search for undocumented hidden legacy infrastructure outside scope.

Part 60 — Assess Administrative APIs

Using the authorized administrator training account, establish an admin baseline.

Then verify that a standard account cannot perform the same API function.

Record:

ADMIN API TEST

Endpoint:

Admin Result:

Standard User Result:

Role Enforcement:
Effective / Weak / Inconclusive

Part 61 — Identify Positive API Controls

Examples include:

Authentication required

Object ownership enforced

Centralized role checks

Strict request schemas

Unknown fields rejected or safely ignored

Sensitive fields omitted

Pagination capped

Collection results scoped

Rate limits applied

Structured generic errors

Deprecated API disabled

State changes audited

Part 62 — Create the Positive Control Register

Control	Endpoint	Result
Object authorization	Orders API	Effective
Schema validation	Profile API	Effective
Pagination cap	Search API	Effective
Admin role enforcement	Admin API	Effective

Part 63 — Potential Finding Categories

Possible findings include:

Unauthenticated API Access

Broken Object Level Authorization

Broken Function Level Authorization

Cross-User Data Exposure

Excessive Data Exposure

Weak API Schema Validation

Sensitive Field Modification

Unrestricted Collection Scope

Insufficient API Rate Controls

Deprecated API Security Weakness

Verbose API Error Disclosure

Part 64 — Finding Example: Broken Object Level Authorization

FINDING ID:
API-001

TITLE:
API Allows Cross-Account Order Access

SEVERITY:
High

CONFIDENCE:
High

ENDPOINT:
/api/v1/orders/{id}

OBSERVATION:
User A was able to request an order belonging to User B by
changing the object identifier in the API request.

VALIDATION:
The returned object contained the known training data belonging
to User B.

IMPACT:
Authenticated users may access API objects outside their
authorized ownership boundary.

EVIDENCE:
EV-API-007

RECOMMENDATION:
Apply object-level authorization to every request using trusted
server-side identity and ownership information.

Part 65 — Finding Example: Broken Function Level Authorization

FINDING ID:
API-002

TITLE:
Standard User Can Access Administrative API Function

SEVERITY:
High / Critical
Depending on function

CONFIDENCE:
High

ENDPOINT:
/api/v1/admin/users

OBSERVATION:
The standard training user successfully invoked an API endpoint
intended for administrators.

IMPACT:
Lower-privileged users may perform or access administrative
functionality.

RECOMMENDATION:
Apply centralized server-side role and permission checks before
executing privileged API operations.

Part 66 — Finding Example: Excessive Data Exposure

FINDING ID:
API-003

TITLE:
Profile API Returns Internal Account Fields to Standard Users

SEVERITY:
Low / Medium
Depending on field sensitivity

CONFIDENCE:
High

OBSERVATION:
The API response returned internal fields not required by the
authorized training client.

IMPACT:
Unnecessary disclosure increases information available to users
and may reveal internal application or account details.

RECOMMENDATION:
Return only fields required for the caller's authorized business
function.

Part 67 — Finding Example: Weak API Schema Validation

FINDING ID:
API-004

TITLE:
Profile API Accepts Unexpected Client-Supplied Fields

CONFIDENCE:
High

OBSERVATION:
The update endpoint accepted and stored an undocumented benign
training field that was not part of the expected request schema.

IMPACT:
Permissive object binding may increase the risk that unintended
fields can influence server-side state.

LIMITATION:
No privileged fields were modified during testing.

RECOMMENDATION:
Define explicit request schemas and allow only intended writable
properties.

Part 68 — Finding Example: Deprecated API Retains Weaker Controls

FINDING ID:
API-005

TITLE:
Deprecated API Version Uses Weaker Authorization Controls

SEVERITY:
High

CONFIDENCE:
High

OBSERVATION:
The current API version correctly denied cross-account access,
while the deprecated training version returned the same
cross-account object.

IMPACT:
Users may bypass security improvements by using an older API
version that remains accessible.

RECOMMENDATION:
Retire vulnerable versions or enforce equivalent security
controls across every supported API version.

Part 69 — Avoid False Findings

Do not report:

API endpoint exists.

as a vulnerability.

Do not report:

JSON contains user ID.

as BOLA.

Do not report:

API accepts GET and POST.

as method bypass.

Do not report:

Response has many fields.

as excessive exposure without assessing necessity and sensitivity.

Part 70 — Build the Findings Register

Finding	Status	Severity	Confidence
Authentication
Object authorization
Function authorization
Schema validation
Data exposure
Collection scope
Rate controls
Legacy API

Part 71 — Build the API Coverage Matrix

Area	Tested	Result
Endpoint inventory	Yes
API versions	Yes
Authentication	Yes
Anonymous access	Yes
User A baseline	Yes
User B baseline	Yes
Object-level authorization	Yes
Write authorization	Yes/NA
Function-level authorization	Yes
HTTP methods	Yes
Schema validation	Yes
Unknown fields	Yes
Data exposure	Yes
Collection scope	Yes
Pagination	Yes
Filtering	Yes
Error handling	Yes
Rate controls	Yes
CORS review	Yes
State-changing operations	Yes
Deprecated versions	Yes/NA

Part 72 — Create the Evidence Register

Example:

Evidence ID	Description
EV-API-001	API inventory
EV-API-002	Authenticated User A baseline
EV-API-003	Authenticated User B baseline
EV-API-004	Anonymous API request
EV-API-005	Own-object request
EV-API-006	Cross-user object request
EV-API-007	Cross-user API response
EV-API-008	Admin API authorization
EV-API-009	Schema-validation test
EV-API-010	Response-field analysis
EV-API-011	Pagination behavior
EV-API-012	Rate-control observation
EV-API-013	Version comparison

Part 73 — Mission Challenge

Complete:

API SECURITY ASSESSMENT

Assessment ID:

Analyst:

Date:


SCOPE

Application:

API Base URL:

Authorized:
Yes / No

API Versions:

Test Accounts:

Roles:


API INVENTORY

Endpoint 01:

Method:

Role:

Purpose:


Endpoint 02:

Method:

Role:

Purpose:


AUTHENTICATION

Mechanism:

Token Location:

Unauthenticated Result:

Protected Data Returned:
Yes / No


USER A BASELINE

Endpoint:

Object:

Status:

Fields Returned:


USER B BASELINE

Endpoint:

Object:

Status:

Fields Returned:


OBJECT AUTHORIZATION

Authenticated As:

Requested Owner:

Endpoint:

Object Returned:
Yes / No

Authorization Enforced:


FUNCTION AUTHORIZATION

Function:

Expected Role:

Standard User Result:

Admin Result:


HTTP METHODS

Endpoint:

Supported Methods:

Unexpected Method Result:


SCHEMA VALIDATION

Required Field Missing:

Wrong Type:

Unknown Field:

Null Value:

Result:


WRITABLE FIELDS

Field:

Expected Writable:

Server Accepted:

Security Sensitive:


DATA EXPOSURE

Endpoint:

Fields Returned:

Unnecessary Fields:

Sensitive Fields:

Assessment:


COLLECTION SCOPE

Endpoint:

Expected Scope:

Observed Scope:


PAGINATION

Default Limit:

Maximum:

Oversize Test:

Result:


FILTERING

Filter:

Expected Scope:

Observed Scope:


RATE CONTROLS

Endpoint:

Small Test Window:

Throttle Observed:

Retry Information:


ERROR HANDLING

Endpoint:

Status:

Technical Detail:

Sensitive Information:


CORS

Allowed Origin:

Credentials:

Expected:


STATE CHANGES

Operation:

Object:

Authorization:

Result:

Restored:


API VERSIONING

v1:

v2:

Security Difference:


LEGACY API

Reachable:

Authentication:

Authorization:

Deprecated:


POSITIVE CONTROLS

Control 01:

Control 02:

Control 03:


FINDINGS

Finding 01:

Severity:

Confidence:

Evidence:


Finding 02:

Severity:

Confidence:

Evidence:


LIMITATIONS

Limitation 01:

Limitation 02:


FINAL ASSESSMENT

API Authentication:
Effective / Weak / Inconclusive

Object Authorization:

Function Authorization:

Schema Validation:

Data Minimization:

Rate Controls:

Legacy API Security:

Overall API Risk:

Ready for Business Logic Assessment:
Yes / No

What Not to Do

Do not:

Use stolen API tokens

Use production credentials

Access real users' data

Modify real records

Delete non-lab data

Attempt mass privilege escalation

Perform high-volume API abuse

Attempt denial of service

Extract complete datasets

Use pagination to scrape unrelated records

Use deprecated APIs outside scope

Modify sensitive role fields unless explicitly authorized

Treat every numeric ID as BOLA

Treat every additional response field as sensitive

Treat CORS as a substitute for authorization

Continue once sufficient evidence has been established

The professional rule is:

Compare authorized identities, objects, roles, schemas, and server decisions with the minimum requests needed to validate each security boundary.

Professional Distinctions

Always distinguish:

API Endpoint
      ≠
API Vulnerability

Authenticated Request
      ≠
Authorized Request

Object Identifier
      ≠
BOLA

Admin Endpoint
      ≠
Broken Function Authorization

Large JSON Response
      ≠
Excessive Data Exposure Automatically

Unknown Field Accepted
      ≠
Mass Assignment Exploit

No Visible Rate Limit
      ≠
Successful API Abuse

CORS Restriction
      ≠
API Authorization

Old API Version
      ≠
Vulnerable API

HTTP 200
      ≠
Authorized Access Automatically

HTTP 403
      ≠
Every API Path Is Secure

API Key
      ≠
User Authorization Automatically

Evidence Requirements

Capture:

assessment scope
Master API Register
API version map
authentication profile
authenticated User A baseline
authenticated User B baseline
unauthenticated request
Authentication Matrix
API Object Register
object-level authorization comparison
object write authorization where permitted
function-level authorization
Method Register
request schema profile
missing-field behavior
wrong-type behavior
unknown-field behavior
writable-field analysis
Response Field Register
collection-scope analysis
pagination behavior
filtering behavior
search/API comparison
API error profile
rate-control profile
response-header review
cache-control review
CORS profile
state-changing API tests
restoration evidence
version comparison
deprecated endpoint review
admin API comparison
positive controls
findings register
coverage matrix
evidence register

Mission Deliverables

Complete:

scope confirmed
API endpoints inventoried
API versions identified
authentication mechanism documented
API secrets redacted
User A baseline established
User B baseline established
anonymous access assessed
authentication matrix completed
object references identified
object-level authorization tested
object-level write authorization assessed safely
function-level authorization assessed
supported HTTP methods documented
method-level security reviewed
JSON schemas documented
missing fields assessed
type validation assessed
unknown fields assessed
writable properties reviewed
excessive data exposure assessed
collection scoping assessed
pagination reviewed
filtering reviewed
search responses reviewed
API errors assessed
rate controls assessed with low volume
API response headers reviewed
cache behavior reviewed
CORS reviewed
state-changing APIs assessed
lab state restored
API versions compared
deprecated versions assessed where applicable
administrative APIs assessed
positive controls documented
findings validated
severity and confidence assigned
final API Security Assessment completed

Lab Report Template

# Lab 12 — API Security Assessment

## Executive Summary

## Mission Objective

## Authorization & Scope

## API Architecture

## API Endpoint Inventory

## API Versioning

## Authentication Mechanisms

## Anonymous Access Assessment

## User A Baseline

## User B Baseline

## Object-Level Authorization

## Function-Level Authorization

## HTTP Method Assessment

## Request Schema Validation

## Writable Field Assessment

## Data Exposure Analysis

## Collection Scope

## Pagination

## Filtering & Search

## API Error Handling

## Rate Controls

## API Response Headers

## Caching

## CORS

## State-Changing Operations

## Deprecated / Legacy APIs

## Administrative APIs

## Positive Security Controls

## Findings

## Severity & Confidence

## Evidence Register

## Limitations

## Recommendations

## Conclusion

Knowledge Check

Question 1 — Why must an API be tested separately from the UI?

Because the UI may hide or restrict functionality while the API still accepts direct requests.

Question 2 — What is Broken Object Level Authorization?

An authorization weakness where a user can access or modify an API object they are not authorized to control.

Question 3 — Does the presence of an object ID prove BOLA?

No.

The server must actually fail the ownership or authorization check.

Question 4 — What is Broken Function Level Authorization?

A condition where a lower-privileged caller can invoke a function intended for a higher-privileged role.

Question 5 — What is excessive data exposure?

Returning data fields to a caller that are unnecessary or inappropriate for the caller’s authorized function.

Question 6 — Why validate API schemas?

Because the server should control which fields, values, and data types the client can influence.

Question 7 — Does accepting an unknown JSON field automatically prove mass assignment?

No.

The security significance depends on whether unintended sensitive server-side properties can be modified.

Question 8 — Why assess deprecated API versions?

Because old versions may remain reachable with weaker security controls even after the current API has been fixed.

Question 9 — Does CORS replace API authorization?

No.

CORS affects browser cross-origin access. API authentication and authorization must still be enforced server-side.

Question 10 — What is the central question?

“Does the API consistently enforce authentication, authorization, input validation, data minimization, and abuse controls regardless of how the client sends the request?”

Skills Achieved

After completing this lab, you should understand:

API inventory development
API version assessment
API authentication
object-level authorization
function-level authorization
BOLA concepts
API method analysis
JSON schema validation
writable-field assessment
excessive data exposure
collection-scope validation
pagination and filtering assessment
rate-control assessment
API error analysis
CORS interpretation
state-changing API assessment
legacy API security
evidence-driven API reporting

Professional Takeaway

A weak API assessment looks like:

Find API
   ↓
Change ID
   ↓
HTTP 200
   ↓
Report BOLA

A professional API assessment looks like:

Inventory API
      ↓
Understand Authentication
      ↓
Build User A Baseline
      ↓
Build User B Baseline
      ↓
Map Objects
      ↓
Change Only Object Context
      ↓
Verify Ownership
      ↓
Assess Read & Write Separately
      ↓
Validate Function-Level Access
      ↓
Assess Request Schema
      ↓
Review Returned Data
      ↓
Assess Collections
      ↓
Assess Rate Controls
      ↓
Compare API Versions
      ↓
Restore Test State
      ↓
Evidence
      ↓
Report

What’s Next?

➡️ Lab 13 — Business Logic & Workflow Security Assessment

In the next lab, you will move beyond individual endpoints and parameters and assess whether the application’s business workflow itself can be used in unintended ways.

You will examine:

workflow states
step ordering
prerequisite checks
state transitions
duplicate actions
replay behavior
quantity and value boundaries
approval workflows
role-dependent workflows
multi-step transactions
client-controlled business fields
process bypass
inconsistent server-side validation
safe race-condition awareness
workflow evidence
business impact

The methodology becomes:

Map Workflow → Establish Intended State → Identify Trust Decisions → Change One Assumption → Observe Transition → Validate Impact → Restore State → Report

The central question will be:

“Can a user remain technically authorized while manipulating the order, state, values, or assumptions of a legitimate workflow to achieve an outcome the business did not intend?”