The draft you could change but could not read

Boundary

Account to draft

Observed effect

Unauthorized draft changes

Engineering focus

Object and action authorization

A denied read, a changed draft

The first response looked right. Two controlled accounts were involved: one owned the draft, and the other had no permission to read it. The second account's read was denied.

The problem showed up in the owner's view. After a separate write by the unrelated account, the owner opened the draft and saw the changed contents. This wasn't just a generous success message. The application had saved an edit from someone it wouldn't let read the same object.

Another operation changed the order of the draft's contents. That mattered because it extended the review beyond a single save action. Editing and rearranging reached the same resource through different paths, and neither enforced the expected permission in the recorded checks.

The draft identifier was already known. Nothing in the notes demonstrates finding unknown identifiers, or progressing the draft to a completed, sent, or signed result. The finding was narrower and concrete: an unrelated controlled account could change stored work that belonged to the other account.

GET /redacted/draft HTTP/1.1
Host: research.example
Cookie: session=[REDACTED]
Accept: application/json

HTTP/1.1 403 Forbidden
Content-Type: application/json
Cache-Control: private, no-store
Content-Length: 25

{"error":"access_denied"}

What the owner's check established

Read and write permissions answer different questions. A denied read tells you the account cannot retrieve the draft through that path. It says nothing about the checks made when an edit, reorder, or later workflow action arrives.

Authentication doesn't close that gap. It identifies the account making the request. An anti-CSRF check helps tie the request to its browser session. The server still needs to ask whether that account may perform this particular action on this particular draft.

The notes don't reveal a missing function, a middleware order, or any other internal cause. They show what the application allowed. The two write operations crossed a boundary that the read operation respected.

That is enough to report a loss of draft integrity. Whether an altered draft could later be sent or approved depends on rules that weren't established here. Those are follow-up questions, not additional impact already proved.

Follow the change into background work

Sections and attachments deserve a check of their own. A valid draft and a valid attachment aren't necessarily a valid pair. Before saving, confirm that every referenced child belongs to the authorized draft and satisfies any extra permission rules.

Background work adds a timing problem. An editor might queue a change, then lose access before a worker applies it. The work item should retain the initiating account, draft, and permitted action; the worker should check the current policy before committing its result. The worker's own service account is not a substitute for the editor's permission.

Removed sharing, changed ownership, and a draft that has moved to a new state can all make queued work invalid. These are repair-review questions. The source notes do not establish that a queue or worker caused this finding.

Five checks before calling it fixed

These local tests use synthetic fixtures in a corrected application. They assert policy and stored state, so a changed response message alone cannot satisfy them.

What a retest still needs to show

A retest should cover save, reorder, child changes, and deferred work wherever those exist. It also needs an invited editor who can still edit and a viewer who cannot. Passing only the denied-owner case would leave both coverage and legitimate sharing unresolved. No completed retest is claimed here.

The useful question isn't whether the draft screen is protected. It's whether every place that saves a change checks who is allowed to make it.