User Controlled Ownership Field
ID |
java.user_controlled_ownership_field |
Severity |
high |
Remediation Complexity |
medium |
Remediation Risk |
medium |
Remediation Effort |
medium |
Resource |
Access Control |
Language |
Java |
Tags |
ASVS50:v8.1.1, CWE:639, CWE:915, NIST.SP.800-53, OWASP:2025:A01, PCI-DSS:6.5.8 |
Description
Data that came from the request reaches the field of a persisted entity that says whose record it is — the customer id, the owner id, the tenant id, whatever this application calls it. The caller therefore decides which account a record belongs to: they can create a record under somebody else’s name, or move one of somebody else’s to themselves.
The detector reports three ways the value gets there:
-
the setter,
order.setCustomerId(request.getParameter("customerId")); -
the direct field write,
order.customerId = id; -
a whole-body copy into the entity —
mapper.readValue(body, Order.class),BeanUtils.copyProperties(form, order)— where the field is never named at all, because the binder writes every field the entity has.
Rationale
This is CWE-915 (mass assignment) read as CWE-639 (authorization bypass through a user-controlled key): the field being assigned is not just any attribute, it is the one the authorization decision is later made on. Every subsequent "is this record yours?" check answers yes, because the request already said so.
Mined from the code |
That the value is request-derived, and that it reaches the assignment: both are decided by the tainting analysis against the shipped library metadata — the request annotations and accessors of the framework in use. No profile is involved. |
Needs a profile fact |
Which field denotes the entity’s owner. Nothing in a rule catalogue can express it, because the
next application calls the field something else; the application’s own convention profile names it
( |
Without that fact this rule has no sink and reports nothing, and says so in the scan log rather
than reporting a clean result it could not establish. Every finding carries the fact it used and the
file:line where that fact can be checked.
The boundary with the API Security mass-assignment detector is the provenance of the field name:
that detector keeps the generic vocabulary (admin, role, scopes, balance) decided from the
endpoint surface, and this one keeps the field the application’s profile named, with a flow proving
the value reaches the entity.
Remediation
Never let the request choose the owner. Set the field from the authenticated principal on the server side:
@PostMapping("/orders")
public Order create(@RequestBody OrderForm form, Principal principal) {
Order order = new Order();
order.setDescription(form.getDescription());
order.setCustomerId(currentCustomerId(principal)); // server-derived, not from the request
return orders.save(order);
}Where a whole-body binder is used, keep the owner field off the bindable surface: a dedicated
request DTO that simply has no such field, @JsonIgnore on the entity’s field, an explicit allow
list (@InitBinder with setAllowedFields, Jackson’s @JsonProperty(access = READ_ONLY)), or an
@PreUpdate/@PrePersist hook that overwrites it from the session. Validating the submitted value
against the caller is a weaker fix than not accepting it, but it is a fix — reject the request when
the submitted owner is not the caller.