Broken Object Property Level Authorization (BOPLA)

Overview

What it means and why it matters

Broken object property level authorization is an API security flaw where a user can read or change a field of an object they are not authorized to access, even if access to the object itself appears allowed.

How it works in practice

An API may correctly verify that a merchant can read its invoice, but return sensitive payout credentials or permit an update to a protected `settlement_address` field through a generic update endpoint. Secure servers apply authorization at both object and property levels using explicit allowlists.

Technical detail without the jargon

For updates, mass assignment can let clients submit hidden or privileged fields. For reads, over-sharing in JSON responses leaks metadata or secrets. Test each role against individual fields, including nested properties, across create, read and update operations.

A deeper point to understand

Property-level checks should apply on every object serialization path, including exports and debugging endpoints, not just the main API response. The attacker may exploit excessive data exposure without changing a field. Use explicit output schemas and role-specific field lists rather than serializing internal model objects wholesale.

Common mistakes and limitations

Hiding fields in frontend forms does not protect them: attackers can send custom HTTP requests. A merchant-level API key should not be able to modify platform administrative fee settings through an invoice object.

What to check in a real payment system

Test invoice and merchant APIs with credentials that may edit benign fields but not settlement destination, owner or fee settings. Try both hidden update fields and overbroad response fields. Verify authorization rejects unauthorized properties on the server, even when the frontend does not display them.

Related concepts

Webhook, Webhook Verification, API Key.

Further reading

OWASP — BOPLA.