Part of objectstack-ai/hotcrm#703
Found during HotCRM's 17.0 GA acceptance sweep on @objectstack/* 17.0.0-rc.2, 5-profile permission matrix phase (188 probes, each user with their own Bearer token).
Symptom
The platform's member_default permission set carries object_permissions["*"] = {allowCreate:true, allowRead:true, allowEdit:true, allowDelete:false} and is union-merged (most-permissive) into every org member. An app's explicit-allow object gate is therefore erased on the create, read and edit axes. Only delete stays profile-driven.
security/explain states it outright — for a profile carrying an explicit all-false deny on crm_opportunity:
create on 'crm_opportunity' is granted by [member_default]
Measured (HotCRM, 17 objects, 5 profiles)
- 21 create-denial probes, ALL returned 201 — every profile creates on every object once validation passes (incl. objects the profile explicitly denies).
member_default also grants own-row EDIT on objects the profile forbids editing (service_agent edited its own crm_account, profile declares no edit anywhere).- On public_read objects the wildcard yields 200 with ALL rows for non-holders — real unauthorized reads, not the documented "200 with 0 rows" empty-set pattern.
Reproduction
# as a user whose profile carries an explicit all-false deny on crm_opportunity
POST /api/v1/data/crm_opportunity {"name":"X","stage":"prospecting","amount":1,"close_date":"2026-09-01", ...}
→ 201
GET /api/v1/security/explain?object=crm_opportunity&operation=create
→ "... granted by [member_default]"Why this matters
The app declares explicit-allow; the platform enforces default-allow-except-delete. App-side authorization test suites validate declarations, so CI is green while the runtime posture is default-open — declared ≠ enforced in the security layer itself. If the wildcard is intentional platform policy, apps need a supported opt-out: explicit deny entries do not win against the union today.
Prior related issues (checked, none open on this defect)
Full probe log: HotCRM acceptance run w4/results.jsonl (M1/M9). Sibling findings from the same sweep: objectstack-ai/hotcrm#705 (write gate), objectstack-ai/hotcrm#704 (parent-derived reads, tracked here as #5386).
Part of objectstack-ai/hotcrm#703
Found during HotCRM's 17.0 GA acceptance sweep on
@objectstack/*17.0.0-rc.2, 5-profile permission matrix phase (188 probes, each user with their own Bearer token).Symptom
The platform's
member_defaultpermission set carriesobject_permissions["*"] = {allowCreate:true, allowRead:true, allowEdit:true, allowDelete:false}and is union-merged (most-permissive) into every org member. An app's explicit-allow object gate is therefore erased on the create, read and edit axes. Only delete stays profile-driven.security/explainstates it outright — for a profile carrying an explicit all-false deny oncrm_opportunity:Measured (HotCRM, 17 objects, 5 profiles)
member_defaultalso grants own-row EDIT on objects the profile forbids editing (service_agent edited its owncrm_account, profile declares no edit anywhere).Reproduction
Why this matters
The app declares explicit-allow; the platform enforces default-allow-except-delete. App-side authorization test suites validate declarations, so CI is green while the runtime posture is default-open — declared ≠ enforced in the security layer itself. If the wildcard is intentional platform policy, apps need a supported opt-out: explicit deny entries do not win against the union today.
Prior related issues (checked, none open on this defect)
public_read_write; this report is aboutmember_default's wildcard under normal OWDsFull probe log: HotCRM acceptance run
w4/results.jsonl(M1/M9). Sibling findings from the same sweep: objectstack-ai/hotcrm#705 (write gate), objectstack-ai/hotcrm#704 (parent-derived reads, tracked here as #5386).