03 API Security

Welcome to:

Module 03 — API Security

Modern applications increasingly depend on APIs.

A user may interact with:

Web Application

Mobile Application

Desktop Application

but behind these interfaces you will often find:

API Endpoints
      ↓
Application Logic
      ↓
Databases
      ↓
Cloud Services

For a Bug Bounty Hunter, this creates an important principle:

Do Not Test
Only the UI

Test the APIs
That Power It

In this module, you will learn how to discover, understand and systematically assess APIs while remaining within authorized scope.

Module Objectives

By the end of this module, you will understand how to:

explain modern API architecture.
understand REST APIs.
understand GraphQL fundamentals.
identify API endpoints.
analyze API requests and responses.
understand HTTP methods in API workflows.
analyze JSON request bodies.
understand API authentication.
analyze API keys and bearer tokens.
understand JWT fundamentals.
test API authorization.
identify Broken Object Level Authorization.
understand Broken Function Level Authorization.
analyze object ownership.
test role boundaries.
identify excessive data exposure.
understand mass assignment.
analyze hidden API parameters.
assess API rate limiting.
understand resource consumption risks.
investigate pagination and filtering.
analyze API versioning.
identify undocumented endpoints.
understand GraphQL authorization risks.
analyze GraphQL queries and mutations.
assess API business logic.
understand API security misconfiguration.
collect API evidence.
build API attack-surface inventories.
write professional API vulnerability reports.

1 — What Is an API?

API stands for:

Application
Programming
Interface

An API allows software components to communicate.

For example:

Mobile App
      ↓
API
      ↓
Application Server
      ↓
Database

Instead of returning HTML, APIs commonly return structured data such as:

{
  "id": 1001,
  "name": "Alice",
  "role": "user"
}

2 — Why APIs Matter to Bug Bounty Hunters

APIs frequently expose:

Authentication

User Profiles

Payments

Files

Orders

Messages

Administration

Cloud Services

Business Workflows

The API may therefore represent:

The Actual
Security Boundary

behind the application.

3 — UI vs API

Suppose the UI shows:

My Profile

but the browser sends:

GET /api/users/1001

The important security question becomes:

Can User A
Request User B's
Object?

not simply:

Can the UI
Display Another
Profile?

4 — API Architecture

A simplified architecture:

Client
      ↓
API Gateway
      ↓
Authentication
      ↓
Application Service
      ↓
Database

More complex environments may contain:

Web Client

Mobile Client

API Gateway

Microservices

Identity Provider

Databases

Cloud Services

Third-Party APIs

5 — REST APIs

REST APIs commonly expose resources through endpoints such as:

/api/users

/api/orders

/api/files

/api/projects

Individual objects may be accessed using:

/api/users/1001

6 — HTTP Methods

REST APIs frequently use:

GET
Read

POST
Create

PUT
Replace

PATCH
Modify

DELETE
Delete

But never assume the method alone determines authorization.

7 — Example API Request

GET /api/v1/profile HTTP/1.1
Host: api.example.com
Authorization: Bearer <token>
Accept: application/json

8 — Example API Response

{
  "id": 1001,
  "username": "research-user",
  "plan": "premium"
}

9 — JSON Requests

APIs commonly accept:

{
  "name": "Research User",
  "email": "research@example.test"
}

Each field creates a question:

Can I Modify It?

Should I Control It?

Does the Server
Validate It?

Does Authorization
Apply to It?

10 — API Attack Surface

Create an inventory of:

Hosts

Versions

Endpoints

Methods

Parameters

Objects

Roles

Tokens

Business Workflows

Think:

API Host
      ↓
Endpoint
      ↓
Method
      ↓
Parameter
      ↓
Object
      ↓
Identity
      ↓
Authorization

11 — Discovering API Endpoints

Within authorized environments, endpoints may be discovered from:

Browser Traffic

Mobile Traffic

JavaScript

API Documentation

Application Routes

Network Requests

Error Messages

12 — Browser Developer Tools

Modern applications frequently make API calls using:

Fetch

XHR

GraphQL

Inspecting application traffic can reveal:

Endpoints

Methods

Parameters

Headers

Response Structures

13 — JavaScript Analysis

Application JavaScript may contain references such as:

/api/v1/users

/api/v2/orders

/graphql

/api/admin

These references help build:

API Attack
Surface

Discovery does not automatically mean authorization.

14 — API Documentation

APIs may expose documentation through technologies such as:

OpenAPI

Swagger

GraphQL Schema

Documentation can reveal:

Endpoints

Parameters

Data Types

Authentication

Response Models

15 — API Inventory

Create:

API_Inventory.csv

with:

Endpoint	Method	Authentication	Role	Object	Purpose

16 — Endpoint Mapping

Example:

/api/users
├── GET
└── POST

/api/users/{id}
├── GET
├── PATCH
└── DELETE

Each combination represents a separate:

Security
Testing Scenario

17 — API Authentication

Authentication identifies:

Who Is
Making the Request?

APIs may use:

Session Cookies

API Keys

Bearer Tokens

JWT

OAuth Tokens

18 — Bearer Tokens

Example:

Authorization: Bearer <access-token>

Possession of the token may represent:

Authenticated
Identity

Treat tokens as sensitive credentials.

19 — API Keys

API keys may identify:

Application

Client

Integration

User

Do not assume:

API Key
      =
User Authorization

The security model depends on implementation.

20 — Token Testing

Questions include:

Does Token Expire?

Can Token
Be Reused?

Does Logout
Invalidate It?

Are Permissions
Embedded?

Can Revoked Tokens
Still Work?

21 — JWT Fundamentals

JWT stands for:

JSON Web Token

A JWT commonly contains:

Header

Payload

Signature

Conceptually:

Header.Payload.Signature

22 — JWT Payload

A payload might contain claims such as:

{
  "sub": "1001",
  "role": "user",
  "exp": 1780000000
}

Remember:

Readable
      ≠
Editable

A properly validated signature should prevent unauthorized modification.

23 — JWT Security Questions

Assess:

Signature Validation

Expiration

Issuer

Audience

Token Type

Key Management

Claim Enforcement

Do not assume a token is vulnerable merely because its contents are readable.

24 — Authentication vs Authorization

Authentication:

This Token
Belongs to
User A

Authorization:

Can User A
Access Object 5001?

Many serious API vulnerabilities occur because:

Authentication Works

but

Authorization Fails

25 — Broken Object Level Authorization

Broken Object Level Authorization is commonly abbreviated:

BOLA

It occurs when an API fails to properly verify whether the authenticated user is allowed to access a particular object.

26 — BOLA Example

Account A owns:

/api/orders/5001

Account B owns:

/api/orders/5002

Account B requests:

GET /api/orders/5001

If the API returns Account A’s private order without authorization:

Potential BOLA

27 — Safe BOLA Testing

Use:

Research Account A

Research Account B

where possible.

Workflow:

Account A
Creates Object
      ↓
Record Object ID
      ↓
Account B
Requests Object
      ↓
Observe Authorization

28 — Object Identifiers

Objects may use:

Sequential IDs

UUIDs

Names

Email Addresses

Tokens

Composite IDs

Important:

Hard-to-Guess ID
      ≠
Authorization

29 — UUIDs

A UUID may make an object difficult to guess.

But if:

User B Obtains
User A's UUID

the server must still enforce:

Authorization

30 — Read vs Write Authorization

Do not test only:

GET

Authorization may differ for:

GET

PATCH

PUT

DELETE

Example:

Cannot Read
Another User's Object

but

Can Modify It

31 — Object Ownership Matrix

Create:

Object_Ownership_Matrix.csv

with:

Object	Owner	User A	User B	Admin

32 — Broken Function Level Authorization

BFLA stands for:

Broken Function
Level Authorization

It concerns access to:

Restricted
Functions

rather than individual objects.

33 — BFLA Example

Normal user:

GET /api/profile

Administrator:

POST /api/admin/users/1001/disable

Ask:

Can Normal User
Call the Admin
Endpoint Directly?

34 — Hidden Admin Functions

The frontend may hide:

Admin Menu

but API endpoints may still exist.

Remember:

Hidden UI
      ≠
Authorization

35 — Role-Based API Testing

Compare requests from:

Guest

User

Premium User

Moderator

Administrator

where these roles exist in an authorized lab.

36 — Authorization Matrix

Create:

API_Authorization_Matrix.csv

with:

Function	Guest	User	Premium	Admin

This helps identify:

Expected
Security Boundaries

37 — Property-Level Authorization

Authorization may also apply to individual object properties.

Example:

{
  "name": "Researcher",
  "email": "user@example.test",
  "role": "user"
}

The user may be allowed to change:

name

but not:

role

38 — Mass Assignment

Mass assignment can occur when an application automatically maps user-provided properties into internal objects without sufficiently restricting sensitive fields.

Example:

{
  "name": "Research User",
  "role": "admin"
}

The security question is:

Does the Server
Accept Sensitive
Properties the User
Should Not Control?

39 — Hidden Properties

Compare:

GET Response

with:

PATCH Request

You may discover fields such as:

role

verified

account_status

discount

permissions

Do not assume they are writable.

Test safely.

40 — Excessive Data Exposure

An API may return more information than the client needs.

Example:

{
  "name": "User",
  "email": "user@example.test",
  "internal_id": "12345",
  "private_field": "..."
}

The key question is:

Should This User
Receive This Data?

41 — Response Analysis

Do not inspect only the fields displayed by the UI.

Inspect:

Complete
API Response

because JavaScript may ignore sensitive fields that are still returned.

42 — Data Minimization

Secure APIs should generally return:

Only the Data
Required

for the authorized operation.

43 — API Enumeration

APIs may expose list endpoints such as:

GET /api/users

GET /api/orders

GET /api/files

Determine:

Who Can List?

What Can They See?

How Much Data
Is Returned?

44 — Pagination

Typical pagination parameters include:

page

limit

offset

cursor

Example:

/api/users?page=1&limit=20

45 — Pagination Security

Ask:

Can Limits
Be Excessive?

Does Pagination
Bypass Authorization?

Can Hidden Records
Be Retrieved?

Use safe values to avoid unnecessary resource consumption.

46 — Filtering

APIs may support:

?user_id=1001

?status=active

?account=123

Filters should not replace authorization.

47 — Sorting

Parameters such as:

sort

order

field

may reveal unexpected application behavior.

Treat them as user-controlled input.

48 — Rate Limiting

APIs often require rate limits for operations such as:

Authentication

OTP

Password Reset

Search

Messaging

Coupon Redemption

49 — Rate-Limit Testing

Determine whether:

Limits Exist

Limits Apply
Per Account

Per Token

Per IP

Per Endpoint

Do not create excessive traffic.

50 — Resource Consumption

Some API requests may be computationally expensive.

Examples:

Large Search

Complex GraphQL Query

Large Export

File Processing

Avoid stress testing unless explicitly authorized.

51 — API Versioning

Applications may expose:

/api/v1/

/api/v2/

/api/v3/

Older versions can be interesting because:

Security Controls
May Differ

52 — Legacy API Versions

Example:

/api/v2/profile

enforces authorization.

But:

/api/v1/profile

may behave differently.

Do not assume old versions are in scope merely because they exist.

53 — Undocumented APIs

Applications may retain:

Legacy Endpoints

Development Endpoints

Internal Routes

Deprecated APIs

These can appear in:

JavaScript

Documentation

Traffic

Historical References

54 — API Error Messages

Errors may reveal:

Internal Object Names

Database Fields

Framework Information

Service Names

Internal Paths

Determine whether disclosure creates meaningful security impact.

55 — API Security Misconfiguration

Potential examples include:

Verbose Errors

Public Documentation

Weak CORS

Debug Endpoints

Unnecessary Methods

Exposed Internal APIs

Impact must always be validated.

56 — Content-Type Handling

APIs may process:

application/json

application/xml

application/x-www-form-urlencoded

multipart/form-data

Different parsers may enforce security controls differently.

57 — Method Handling

If an endpoint expects:

POST

understand how it behaves with other supported methods.

Do not assume:

Method Restriction
      =
Authorization

58 — Parameter Location

The same value might appear in:

URL

Header

Cookie

JSON Body

Map where the server obtains:

Identity

Object ID

Role

State

59 — Duplicate Parameters

Applications and intermediary systems can sometimes interpret duplicate parameters differently.

This becomes relevant when:

Multiple Layers
Parse the Request

Focus on understanding behavior rather than blindly mutating requests.

60 — API Business Logic

API testing is not only about technical vulnerabilities.

APIs implement:

Business Rules

such as:

Purchases

Refunds

Subscriptions

Invitations

Approvals

Credits

Rewards

61 — Business Logic Example

Workflow:

Create Order
      ↓
Pay
      ↓
Complete
      ↓
Refund

Ask:

Can Order
Complete Without
Payment?

62 — State Transition Testing

Map:

Pending
      ↓
Approved
      ↓
Completed

Then ask:

Can User Move
Directly from
Pending to Completed?

63 — Client-Controlled State

Example:

{
  "status": "approved"
}

Ask:

Should the Client
Control This Field?

64 — Price and Quantity

Example:

{
  "product_id": 100,
  "quantity": 1
}

Investigate whether the server independently calculates:

Price

Discount

Total

65 — Workflow Replay

Some operations should be:

Single Use

Examples:

Coupon

Invite

Reset Token

Payment Action

Determine whether replay creates unauthorized effects.

66 — API Race Conditions

Certain workflows may behave incorrectly when requests occur concurrently.

Potential areas:

Coupons

Inventory

Rewards

Withdrawals

Invitations

Only test concurrency in safe training environments or where explicitly permitted.

67 — REST Resource Thinking

For every resource ask:

Who Can Create?

Who Can Read?

Who Can Update?

Who Can Delete?

This gives:

CRUD
Authorization Matrix

68 — CRUD Matrix

Create:

Resource	Create	Read	Update	Delete
Profile	User	Owner	Owner	Owner
User	Admin	Admin	Admin	Admin
File	User	Owner	Owner	Owner

Then validate server behavior.

69 — GraphQL

GraphQL provides a flexible query interface commonly exposed through an endpoint such as:

/graphql

Unlike REST:

Many Operations
May Share
One Endpoint

70 — GraphQL Query

Conceptually:

query {
  profile {
    id
    username
  }
}

71 — GraphQL Mutation

Mutations modify state.

Conceptually:

mutation {
  updateProfile(name: "Research User") {
    id
    name
  }
}

72 — GraphQL Attack Surface

Map:

Queries

Mutations

Objects

Fields

Arguments

Roles

73 — GraphQL Authorization

Authorization must still apply to:

Objects

Fields

Functions

GraphQL does not automatically provide access control.

74 — GraphQL Object Authorization

Suppose:

user(id: "1001")

returns another user’s private information.

The underlying problem may still be:

Broken Object
Authorization

75 — GraphQL Field Authorization

A user may be allowed to access:

name

but not:

internalNotes

Field-level authorization therefore matters.

76 — GraphQL Introspection

GraphQL may support schema introspection.

It can reveal:

Types

Queries

Mutations

Fields

Arguments

Whether introspection exposure itself is a vulnerability depends on context.

77 — GraphQL Complexity

GraphQL allows flexible queries.

Complex queries can potentially create:

Resource
Consumption

risks.

Do not perform stress testing without explicit authorization.

78 — Mobile APIs

Mobile applications frequently communicate with the same or similar APIs used by web applications.

Therefore:

Mobile UI
      ↓
API

should be understood as part of the broader application architecture.

79 — Mobile vs Web API

Compare:

Web API

Mobile API

Security controls may differ because of:

Different Versions

Different Clients

Legacy Implementations

80 — API Trust Boundaries

Identify where trust changes:

Client
      ↓
API Gateway
      ↓
Service
      ↓
Database

Ask:

Which Layer
Authenticates?

Which Layer
Authorizes?

Which Layer
Validates Input?

81 — Microservices

Modern APIs may call multiple internal services.

Example:

API Gateway
      ↓
Order Service
      ↓
Payment Service
      ↓
Notification Service

Security assumptions between services can create vulnerabilities.

82 — API Gateway

An API gateway may provide:

Authentication

Rate Limiting

Routing

Logging

but backend services should not blindly assume every request is trustworthy.

83 — Trusting Client Claims

Suppose request contains:

{
  "user_id": "1001"
}

Ask:

Does the Server
Trust This Value

or

Derive Identity
from Authentication?

84 — Identity Source

Determine whether identity comes from:

Session

JWT

API Key

Request Parameter

Header

This is fundamental to authorization testing.

85 — Object Source

Determine how the server identifies the resource:

URL ID

JSON ID

Query Parameter

Token Claim

Then compare:

Identity
vs
Object Ownership

86 — API Security Testing Model

For every request ask:

Who Am I?

What Am I
Requesting?

Do I Own It?

What Role
Do I Have?

What Input
Can I Control?

What Should
the Server Enforce?

87 — Differential API Testing

Compare:

Account A Request

vs

Account B Request

Then compare:

User Request

vs

Admin Request

Look at:

Endpoint

Method

Headers

Body

Response

88 — Baseline API Request

Always preserve:

Known-Good
Request

before modifying:

Token

Object ID

Role

Method

Parameter

89 — Change One Variable

Example:

Baseline
User A + Object A

Change only:

Object A
      ↓
Object B

This makes the authorization test easier to understand.

90 — API Response Comparison

Compare:

Status

Length

Fields

Values

Headers

Timing

Do not rely only on:

91 — HTTP 200 Is Not Proof

Response:

HTTP/1.1 200 OK

may contain:

{
  "error": "Access denied"
}

Always inspect the actual response.

92 — HTTP 403 Is Not Always Safe

Likewise, inspect whether a denied response accidentally contains:

Sensitive
Information

93 — API Evidence

Strong evidence includes:

Account A Identity

Account B Identity

Object Ownership

Baseline Request

Unauthorized Request

Response

Security Impact

94 — BOLA Evidence Example

Document:

Account A
owns object 5001.

Account B
is authenticated separately.

Account B requests
object 5001.

API returns
Account A's private object.

This clearly demonstrates:

Ownership
      +
Unauthorized Access

95 — Weak API Evidence

Weak:

Changing ID
Returns 200

Strong:

Changing Account B's
object ID to Account A's
object ID returns Account A's
private billing record.

96 — API Vulnerability Report

Your report should contain:

Title

Endpoint

Method

Authentication

Affected Role

Prerequisites

Reproduction

Request

Response

Impact

Remediation

97 — API Report Title

Weak:

API IDOR

Better:

Broken Object-Level
Authorization Allows
Authenticated Users
to Access Other Users'
Private Documents

98 — API Impact

Explain:

What Data
Can Be Accessed?

What Action
Can Be Performed?

Who Is Affected?

What Privilege
Is Required?

99 — API Remediation

Depending on the issue, recommendations may include:

Server-Side
Authorization

Object Ownership
Validation

Role Validation

Property Allowlisting

Data Minimization

Rate Limiting

100 — Build an API Testing Notebook

Create:

API_Security_Notebook.md

with:

# API Hosts

# Versions

# Authentication

# Roles

# Endpoints

# Objects

# Parameters

# Authorization

# Business Logic

# GraphQL

# Vulnerability Candidates

# Evidence

# Reports

101 — Endpoint Register

Create:

API_Endpoint_Register.csv

with:

Endpoint	Method	Auth	Role	Object	Parameters

102 — Object Register

Create:

API_Object_Register.csv

with:

Object	Identifier	Owner	Sensitivity	Operations

103 — Parameter Register

Create:

API_Parameter_Register.csv

with:

Parameter	Endpoint	Location	Type	Security Relevance

104 — Role Matrix

Create:

API_Role_Matrix.csv

with:

Endpoint	Guest	User	Premium	Admin

105 — API Hypothesis Register

Create:

API_Hypotheses.csv

with:

ID	Endpoint	Hypothesis	Test	Result	Status

106 — Example Hypotheses

Can User B
Read User A's
Object?

Can User
Call Admin
Function?

Can Sensitive
Property Be Modified?

Can Revoked Token
Still Work?

Can Legacy API
Bypass New Control?

107 — API Vulnerability Candidates

Create:

API_Vulnerability_Candidates.csv

with:

Finding	Endpoint	Evidence	Impact	Status

108 — API Testing Workflow

Use:

Discover
      ↓
Inventory
      ↓
Authenticate
      ↓
Understand Objects
      ↓
Map Roles
      ↓
Build Baseline
      ↓
Create Hypothesis
      ↓
Modify Request
      ↓
Compare Response
      ↓
Validate
      ↓
Document
      ↓
Report

109 — Think in Objects

Instead of asking:

Is This API
Vulnerable?

ask:

What Objects
Exist?

Who Owns Them?

Who Can Read Them?

Who Can Modify Them?

Who Can Delete Them?

110 — Think in Functions

Then ask:

What Functions
Exist?

Which Roles
Should Access Them?

Can Lower Roles
Call Them Directly?

111 — Think in Properties

Then:

Which Fields
Can Users Control?

Which Fields
Should Be
Server-Controlled?

112 — Think in Workflows

Finally:

What Business
Process Does
This API Implement?

Can Steps
Be Skipped?

Can Actions
Be Replayed?

Can State
Be Manipulated?

Practical Exercise 1 — Build an API Inventory

Using an authorized training application, identify:

API Host

Version

Endpoints

Methods

Authentication

Create:

API_Inventory.csv

Practical Exercise 2 — Map 20 API Endpoints

Document at least:

20
Endpoint + Method
Combinations

where available.

Classify each by:

Authentication

Role

Object

Function

Practical Exercise 3 — Build Object Inventory

Identify:

Users

Files

Orders

Projects

Messages

where available.

Document:

Identifier

Owner

Operations

Sensitivity

Practical Exercise 4 — Two-Account BOLA Test

Using your own training accounts:

Account A
Creates Object
      ↓
Account B
Attempts Read
      ↓
Account B
Attempts Update

Document the authorization behavior.

Practical Exercise 5 — Function Authorization

Create:

Normal User

Admin User

in an authorized lab.

Compare:

Admin Functions

Normal Functions

and validate that restricted API operations enforce authorization server-side.

Practical Exercise 6 — Property Testing

Take an editable profile object.

Identify:

User-Controlled Fields

Server-Controlled Fields

Test whether sensitive fields are appropriately protected.

Practical Exercise 7 — Token Lifecycle

Document:

Token Creation

Expiration

Logout

Password Change

Revocation

and observe expected token behavior.

Practical Exercise 8 — API Version Comparison

If your training environment exposes:

v1

v2

compare:

Authentication

Authorization

Response Fields

Methods

Practical Exercise 9 — GraphQL Mapping

In an authorized GraphQL lab, identify:

Queries

Mutations

Objects

Fields

Arguments

and create:

GraphQL_Attack_Surface.md

Practical Exercise 10 — API Business Logic

Select one workflow:

Order

Coupon

Invite

Subscription

Approval

Document:

Normal Sequence

State Changes

Security Boundaries

Potential Abuse Cases

Practical Exercise 11 — Build Authorization Matrix

Create:

API_Authorization_Matrix.csv

for:

Guest

User A

User B

Admin

across at least ten operations.

Practical Exercise 12 — Write an API Vulnerability Report

Create a professional report for a fictional:

Broken Object
Level Authorization

finding.

Include:

Title

Endpoint

Method

Accounts

Object Ownership

Baseline Request

Unauthorized Request

Response

Impact

Remediation

Knowledge Check

What is an API?
Why are APIs important in bug bounty hunting?
What is REST?
What are common REST methods?
What is an API endpoint?
What information can JavaScript reveal about APIs?
What is OpenAPI?
What is API authentication?
What is a bearer token?
What is an API key?
What is a JWT?
Why does readable JWT content not mean the token is editable?
What is the difference between authentication and authorization?
What is BOLA?
Why should two controlled accounts be used for BOLA testing?
Why are UUIDs not authorization controls?
Why should read and write authorization both be tested?
What is BFLA?
Why does a hidden admin interface not provide authorization?
What is property-level authorization?
What is mass assignment?
What is excessive data exposure?
Why should complete API responses be reviewed?
Why should filters not replace authorization?
What is API rate limiting?
Why must resource-consumption testing be controlled?
Why are legacy API versions interesting?
What are undocumented APIs?
What information can API errors expose?
What is API security misconfiguration?
Why does Content-Type matter?
What is API business logic?
What is state-transition testing?
Why can replayable actions create security issues?
What is a CRUD authorization matrix?
What is GraphQL?
What is a GraphQL query?
What is a GraphQL mutation?
Why does GraphQL still require object-level authorization?
What is field-level authorization?
What is GraphQL introspection?
Why can GraphQL complexity create resource risks?
Why should mobile APIs be assessed?
What is an API gateway?
Why should backend services not blindly trust gateway assumptions?
Why is determining the identity source important?
What is differential API testing?
Why should one request variable be changed at a time?
What makes strong BOLA evidence?
What should a professional API vulnerability report contain?

Key Takeaways

API security requires thinking in:

Identity

Objects

Functions

Properties

Roles

State

Business Logic

For every API request ask:

Who Am I?
      ↓
What Object
Am I Accessing?
      ↓
Do I Own It?
      ↓
What Role
Do I Have?
      ↓
What Action
Am I Performing?
      ↓
Should the Server
Allow It?

Remember:

Authentication
      ≠
Authorization

UUID
      ≠
Authorization

Hidden Endpoint
      ≠
Protected Endpoint

Hidden Field
      ≠
Protected Property

HTTP 200
      ≠
Successful Exploit

API Response
      ≠
Only What
the UI Displays

A professional API testing methodology is:

Discover
      ↓
Map
      ↓
Understand Identity
      ↓
Understand Objects
      ↓
Understand Roles
      ↓
Build Baseline
      ↓
Create Hypothesis
      ↓
Test
      ↓
Compare
      ↓
Validate
      ↓
Report

Career Connection

API security skills are increasingly important for:

Bug Bounty Hunters

Security Researchers

Application Security Engineers

API Security Analysts

Penetration Testers

Cloud Security Engineers

During interviews, you should be able to explain:

How You
Discover APIs

How You
Map Endpoints

How You
Identify Objects

How You
Test BOLA

How You
Test BFLA

How You
Analyze Tokens

How You
Assess Properties

How You
Test Business Logic

How You
Validate Impact

Instead of saying:

I Test
API Endpoints

you should be able to explain:

I first map the API's
endpoints, methods,
objects and authentication
model.

I identify the relationship
between authenticated
identities and application
objects.

I then build authorization
matrices across users,
roles, functions and
properties.

Using controlled accounts,
I test whether server-side
authorization remains
enforced when object IDs,
roles, methods or
properties change.

Finally, I validate the
business impact and
document reproducible
evidence.

What’s Next?

➡️ Next: 04 — Mobile Security

You now understand how applications expose functionality through:

APIs

Objects

Tokens

Roles

Endpoints

Business Workflows

The next module extends this knowledge into:

Mobile Applications

You will learn how Android and iOS applications interact with:

Application Packages

Local Storage

Configuration

Deep Links

Authentication

Tokens

WebViews

Mobile APIs

Backend Services

You will move from:

Testing
Web and API
Interfaces

to:

Understanding
the Mobile Client

      +

Testing the
Backend Services
That Power It

using:

Mobile Application
      ↓
Application Package
      ↓
Configuration
      ↓
Local Data
      ↓
Network Traffic
      ↓
API
      ↓
Authentication
      ↓
Authorization
      ↓
Business Logic

➡️ Next: 04 — Mobile Security