Mass assignment review: separate writable fields from stored fields

Sources checked: 29 October 2026. This article contains FailSafe's analysis and proposed validation workflow; linked sources support the reported facts.

A mass assignment review examines whether an API accepts fields the caller is not allowed to change. The key artifact is a field-level policy that separates ordinary profile input from ownership, entitlement, approval, and administrative state.

OWASP treats unauthorized property access and modification as object-property authorization risks. OWASP API3:2023 provides the underlying reference. The assessment design below is an original defensive example, not a report of a customer incident.

Inventory fields by business authority

Start with one high-value object and list which fields are caller-controlled, server-derived, administrator-controlled, or calculated. An account record may combine display preferences with account status, organization ownership, and commercial entitlements. Those fields can share storage without sharing permission rules. Include nested objects and bulk import formats, since their validation paths may differ. Ask engineers which schema defines the public write contract and which fields can appear only in a database model or internal event.

Construct a synthetic preference-change case

Create a test user with a known low-privilege membership and a harmless preference. Exercise an allowed update first, confirming the account remains in the expected role and organization. Under owner supervision, assess whether the service rejects or ignores disallowed administrative properties in the same update workflow. Record the field names privately in the assessment materials, without publishing a working request. Keep the test tenant disconnected from live billing, email delivery, and external provisioning to limit accidental effects.

Inspect persistence and downstream consumers

A response can omit a prohibited field while still persisting it. Compare the stored test object and any emitted event through approved observability tools. Check whether a worker, search index, or identity synchronization job uses a value that the request handler should have discarded. The assessment should also consider response properties: sensitive internal fields can be exposed even when they cannot be written. Treat read and write behavior as separate cases, each with its own expected outcome and evidence record.

Use the result to improve contracts

Report the affected field category, caller role, accepted input path, and proven state change. Recommend an explicit external input contract and a separate authorization decision for privileged changes, subject to the application's architecture. Retest legitimate preferences to catch overly broad remediation that breaks normal updates. Then check a neighboring object only if authorized. A successful fix for one serializer does not prove that all imports, batch endpoints, or administrative APIs use the same contract.

A useful assessment artifact

Create a field decision sheet for the chosen object. Mark each property readable, writable, server-derived, or restricted for each tested role. Engineers can compare that sheet with serializers and update contracts without relying on a particular testing tool.

Plan an assessment

Discuss the authorized scope and required evidence with FailSafe SWARM. For a business evaluating an initial engagement, review the first-pentest offer and confirm scope before purchase.