Sensitive fields must not enter the draft
Aliases: draft excludes secrets · no CVV in autosave · password not in draft
What it is
A draft writes values to disk or to a server so interruptions do not kill them—and thereby creates a second copy that often lives longer, and is guarded less, than the submitted record. Sensitive fields stay out of the draft means passwords, payment security codes, ID scans, and one-time codes are stripped at autosave; submit may still send them. When people return, those boxes are empty and must be filled again. This entry does not argue whether long forms should save, or how status copy should read. It only argues what a draft must not contain. The browser writing payment data into an autofill store is a different source.
Why it happens
A draft’s threat surface is not the same as a successful submitted record. Local storage can be read by other pages on the machine, by backups, and by forensics. Server drafts often have less encryption, more replicas, and less audit than the official store, and they leave the device while the person still believes “I did not submit.” Sensitive values harm by leaking, not by being lost; the interruption cost (type the password again) is far smaller than the copy cost. A second layer: exclusion must happen before the write, not as a later delete. Mobile backups, logs, and crash dumps will have copied the value before “clean up shortly” runs. The interface also must not pretend those items were saved. Status saying “Saved” while a password box looks filled (dots) makes people think closing is safe. Next open they find it empty—or worse, the dots came from a value that was not excluded. The right shape for OTP and CVV is: absent from the draft, field empty, asked again at submit.
Studying it
Inspect draft payloads (local storage, API, crash logs) and list which fields appear. Scenario-test: save, switch device, export a backup, open the developer storage panel.
Independent variables: field type (password / CVV / ID image / ordinary text), whether exclusion happens on the client or only as a display hide, whether drafts enter backups. Dependent variables: whether the sensitive value appears in any draft payload, whether users believe the sensitive item was saved, abandonment caused by having to refill after exclusion.
Do not only look for dots in the UI. Dots can be CSS over plaintext. A security review catches this entry better than a completion-rate experiment. Record a rise in abandonment separately from a leak; “refill is annoying” does not veto exclusion.
Where it stops holding
Symptom narrative on a long medical form matters for restore and for leak risk: it belongs in an encrypted server draft with the same access control as the official record, not in local plaintext. A user choosing “remember password” is the password manager, not the form draft. On a dedicated terminal on a trusted intranet with local storage forbidden, the exclusion list can shorten—but still do not write CVV or OTP into any exportable draft. A successfully submitted official store is not a draft; retention follows official data policy.
Applying it
- Keep an exclusion list in draft serialization: passwords, OTP, CVV, ID images, full payment-account numbers. Submit requests may include them; draft requests must strip them.
- After restoring a draft those fields stay empty. Do not fake presence with dots or a truncated value. If needed, say in place “this item must be entered again.”
- Inspect local storage, crash logs, and backup channels and confirm exclusion happens before the first write.
- Verify by entering a password and CVV, triggering autosave, and opening the storage panel and the draft API: those values are absent. After restore both boxes are empty. Write the password into local storage on purpose as a counterexample and confirm release checks block it.