Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-10-05 14:46:55 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 4
bcquality/microsoft/knowledge/web-services/disable-write-operations-on-read-only-api-pages.md
Jesper Schulz-Wedde 2b5550c346
Some checks failed
Validate knowledge index / validate-index (push) Has been cancelled
Details
Validate AL review fixtures / validate-review-fixtures (push) Has been cancelled
Details
Validate frontmatter and structure / validate (push) Has been cancelled
Details
Improve partner onboarding and documentation navigation (#174) 
Lead with a complete plugin quick start and add task-oriented usage, troubleshooting, customization, and contribution guides. Preserve the broader plugin framing, correct conflicting contract guidance, support Agents folder reviews, and align repository validation. Convert existing sample references to clickable links without changing knowledge rules.

Co-authored-by: Jesper Schulz-Wedde <jesper.schulzwedde@microsoft.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
2026-09-09 17:31:03 +02:00

2.1 KiB
Raw Blame History

bc-version domain keywords technologies countries application-area
all
web-services
api-page
insertallowed
modifyallowed
deleteallowed
editable
read-only
reporting-api
al
w1
all

Lock down write operations on read-only API pages

Description

An API meant purely for reading — a reporting or lookup endpoint — is not read-only just because nobody intends to write to it. Unless the page explicitly forbids writes, the platform leaves the endpoint writable, so a client can POST, PATCH, or DELETE against data that was never meant to change through that surface. The fix is explicit: set InsertAllowed = false, ModifyAllowed = false, and DeleteAllowed = false (and Editable = false) so the endpoint rejects every write operation. LLMs often assume "I only exposed read fields, so it's read-only" and rely on defaults; this file is remedial because the default for an API page is writable, and the read-only intent has to be encoded as three explicit property settings, not inferred.

Best Practice

For a read-only / reporting API page set all three CRUD guards off — InsertAllowed = false, ModifyAllowed = false, DeleteAllowed = false — and mark the page Editable = false. The endpoint then serves GET requests and rejects any insert, modify, or delete, matching the read-only contract regardless of the caller. Make the read-only stance explicit rather than depending on the writable default.

See sample: disable-write-operations-on-read-only-api-pages.good.al.

Anti Pattern

An API intended for read-only consumption that omits the CRUD guards, leaving InsertAllowed, ModifyAllowed, and DeleteAllowed at their writable defaults. The endpoint silently accepts POST, PATCH, and DELETE, so a client can mutate or remove data the API was never meant to expose for writing. The detection signal: a read-only/reporting PageType = API page that does not set the three *Allowed = false properties.

See sample: disable-write-operations-on-read-only-api-pages.bad.al.