[Security] GeneratorBrands write endpoints allow any authenticated user to modify CRM reference data (#689 follow-up) #694

New Issue

2026-07-17T23:20:49Z

spikerj commented

2026-07-17 23:20:49 +00:00

Follow-up to spikersoft-issues#689 / #415. GeneratorBrandsController intentionally keeps its GET endpoints public (reference/lookup data — brand dropdown). But its write endpoints — POST (create), PUT (update), DELETE — are gated only by a bare [Authorize] (any authenticated user). #415 stopped anonymous writes but did not restrict to staff.

So any platform account (e.g. a student/consumer sharing the API's Keycloak realm) can create, edit, or delete generator-brand catalog entries — reference-data pollution / integrity loss for the generator-service CRM. The sibling CRM controllers are already staff-gated (#689); GeneratorBrands is the same CRM data, just with public reads, so only its writes need tightening (class-level gating would have broken the public reads — hence method-level here).

Fix (this PR)

Gate the three write endpoints with [Authorize(Roles = "Admin,admin,Staff,staff")]; leave the GETs public. Added a test asserting the writes require the staff role while the reads stay public.

Follow-up to spikersoft-issues#689 / #415. `GeneratorBrandsController` intentionally keeps its `GET` endpoints public (reference/lookup data — brand dropdown). But its **write** endpoints — `POST` (create), `PUT` (update), `DELETE` — are gated only by a bare `[Authorize]` (any authenticated user). #415 stopped *anonymous* writes but did not restrict to staff. So any platform account (e.g. a student/consumer sharing the API's Keycloak realm) can create, edit, or delete generator-brand catalog entries — reference-data pollution / integrity loss for the generator-service CRM. The sibling CRM controllers are already staff-gated (#689); GeneratorBrands is the same CRM data, just with public reads, so only its writes need tightening (class-level gating would have broken the public reads — hence method-level here). ## Fix (this PR) Gate the three write endpoints with `[Authorize(Roles = "Admin,admin,Staff,staff")]`; leave the `GET`s public. Added a test asserting the writes require the staff role while the reads stay public.

spikerj commented

2026-07-17 23:29:30 +00:00

Resolved in spikersoft-backend PR #389 (merged to master). Gated GeneratorBrands POST/PUT/DELETE to [Authorize(Roles = "Admin,admin,Staff,staff")] (method-level; public GET reads preserved). 5 authorization tests pass. This completes the CRM access-control hardening (#688/#689/#694). Closing.

Resolved in spikersoft-backend PR #389 (merged to `master`). Gated GeneratorBrands POST/PUT/DELETE to `[Authorize(Roles = "Admin,admin,Staff,staff")]` (method-level; public GET reads preserved). 5 authorization tests pass. This completes the CRM access-control hardening (#688/#689/#694). Closing.

spikerj closed this issue

2026-07-17 23:29:30 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: spikerj/spikersoft-issues#694