A store install creates, and can never replace a local object

[rubenvdlinde]

Found reviewing my own merged code from #1677. It is a hole in the boundary that PR was largely about, so it is worth stating plainly rather than filing quietly.

The defect

OpenRegister resolves the object it writes from the payload itself. ObjectService::extractUuidAndNormalizeObject() reads:

$providedId = $object['@self']['id'] ?? $object['id'] ?? null;

and treats a match as the uuid to UPDATE. saveObject is PUT-semantic, so keys the payload omits are nulled rather than left alone.

So a store item whose component carried the uuid of this municipality's live case type would not merely change it — it would gut it. Through a button labelled Install.

Why the allowlist did not catch it

INSTALLABLE_SLUGS governs which schema a component may write. It says nothing about whether the write creates or replaces. A component naming caseType is entirely legitimate — it is exactly what the store exists for — and that is what makes it the attack.

I wrote that allowlist and called it the security boundary. It was half of one.

The fix

id, uuid and @self are stripped before the write, so an installed component is always a new local object. Identity is not a remote registry's to supply.

If install ever needs to be idempotent, it must key on something dossiq controls rather than on a remote id.

Evidence

The test carries a negative control: removing the strip makes testAnInstalledComponentCannotOverwriteAnExistingObject fail. It asserts @self too, not just id, because @self.id is the one saveObject reads first.

2768 PHPUnit tests, phpstan clean.

🤖 Generated with Claude Code

[rubenvdlinde]

Swept the defect class rather than just this instance.

openbuild, the other GenericStoreService consumer, does NOT have this hole, and is structurally immune rather than accidentally safe. Its install never hands the remote payload to a write:

• installFromTemplateArray() refuses on slug collision with a 409 before writing anything;
• materialiseApplication() builds a NEW Application — new slug, owner-tagged record, companion-schema namespacing — so identity is minted locally and the remote template is a source of content only;
• nothing in that path reads $template['id'], ['uuid'] or ['@self'].

dossiq's install was the outlier: it passed the component's object array straight to ConfiguredRegistryService::save(), and that is what let the remote id become the addressed object.

Worth stating for whoever writes the third consumer, since ADR-080 Decision 3 deliberately leaves install to each app: the engine gives you resolve(), and what comes back is somebody else's data. Build a new record from it; never write it.

[github-actions]

Quality Report — ConductionNL/dossiq @ 4e554bb

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-manifest		✅
check-vue3-compile		✅
test-l10n		✅
format		✅
check-schema-l10n		✅
check-l10n-js		✅
composer			✅	✅ 106/106
npm			✅	✅ 540/540
app:check-code	⏭️
info.xml	✅
REUSE	❌
PHPUnit					✅
Newman					⏭️
Playwright					⏭️ deferred — runs on the promotion into beta/main, not on a pull request into development
Hydra gates					✅

---

Quality workflow — 2026-09-02 19:21 UTC

Download the full PDF report from the workflow artifacts.