Scenario POST response may leak owner (no normalizationContext on Post) #69

New issue

Open

opened 2026-07-07 10:15:44 +02:00 by myrmidex · 0 comments

myrmidex commented

2026-07-07 10:15:44 +02:00

Owner

Bug (suspected — needs a characterization test to confirm)

POST /api/scenarios has no normalizationContext, so its response serializes all readable properties ignoring #[Groups] (same API Platform gotcha as #68, but for the write op). Scenario::$owner carries no #[Groups] and is populated before serialization (ScenarioOwnerProcessor::process() sets it pre-persist), so the POST response likely embeds the nested User — potentially including roles and the hashed password.

Severity is moderate, not critical: it's the hashed password, not plaintext, and only the authenticated owner sees their own POST response. But it's still an unintended internal-entity leak on the write path.

Why separate from #68

#68 fixed the collection/item read ops (added scenario:summary). It deliberately left Post untouched to stay scoped. Get/GetCollection now correctly exclude owner (explicit non-empty group contexts); Post is the last op with implicit "serialize everything" behavior. Pre-existing — predates #68.

Fix

First: characterization test — dump a real POST /api/scenarios response body and assert whether owner/password appear (settle it empirically before changing behavior).
If it leaks: give Post an explicit normalizationContext (reuse scenario:summary, or a dedicated response group) so it returns the same lean/safe shape as the other ops. Add a test asserting owner is absent from the POST response (mirrors testGetItemDoesNotExposeOwner, which only covers Get today).

Notes

Serialization-only; no migration.
Surfaced by pr-review of #68 (collection-leak fix), during #54's finish phase.
Consider auditing Bucket/Stream POST ops for the same implicit-all-props behavior while here.

## Bug (suspected — needs a characterization test to confirm) `POST /api/scenarios` has **no `normalizationContext`**, so its response serializes all readable properties ignoring `#[Groups]` (same API Platform gotcha as #68, but for the write op). `Scenario::$owner` carries no `#[Groups]` and is populated before serialization (`ScenarioOwnerProcessor::process()` sets it pre-persist), so the POST response likely embeds the nested `User` — potentially including `roles` and the **hashed** password. Severity is moderate, not critical: it's the *hashed* password, not plaintext, and only the authenticated owner sees their own POST response. But it's still an unintended internal-entity leak on the write path. ## Why separate from #68 #68 fixed the **collection/item** read ops (added `scenario:summary`). It deliberately left `Post` untouched to stay scoped. `Get`/`GetCollection` now correctly exclude `owner` (explicit non-empty group contexts); `Post` is the last op with implicit "serialize everything" behavior. Pre-existing — predates #68. ## Fix 1. First: characterization test — dump a real `POST /api/scenarios` response body and assert whether `owner`/`password` appear (settle it empirically before changing behavior). 2. If it leaks: give `Post` an explicit `normalizationContext` (reuse `scenario:summary`, or a dedicated response group) so it returns the same lean/safe shape as the other ops. Add a test asserting `owner` is absent from the POST response (mirrors `testGetItemDoesNotExposeOwner`, which only covers `Get` today). ## Notes - Serialization-only; no migration. - Surfaced by pr-review of #68 (collection-leak fix), during #54's finish phase. - Consider auditing `Bucket`/`Stream` POST ops for the same implicit-all-props behavior while here.