Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Rule proposal: form-prefill-sanitize — extend checkout-checkbox-sanitize to text/email/select prefills

Open
#121 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
38/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
typescript
Domain
frontend, security

Research direction

Start by reading the existing checkout-checkbox-sanitize and cart-addon-annotate rules and reuse their checkout URL gate. Define the new rule around DOMContentLoaded, the listed control types, hidden-input allowlist and denylist, focus checks, select field restrictions, and host kill-switch; done means covered behavior is tested without touching protected fields or non-checkout forms.

Written by the indexing model from the issue text.

Description

enhancement rule-proposal
Category

New defense rule (extension of the checkout-checkbox-sanitize family)

What problem does this solve?

checkout-checkbox-sanitize clears pre-checked checkboxes on checkout pages so the agent doesn't inherit silent opt-ins. The same dark pattern — Mathur et al.'s Preselection — exists for non-checkbox inputs:

  • Pre-populated <select> defaults that pick the costliest shipping speed
  • Pre-filled hidden inputs carrying affiliate / referral / promo IDs that bias pricing or attribution
  • Pre-filled email/phone fields nudging the user toward marketing signup
  • Pre-selected radio defaults on tipping prompts ("18% / 20% / 22% / Custom" with 22% pre-checked)

The agent is then expected to re-select what it actually wants, same contract as the existing checkbox rule.

Proposed solution

On the same checkout-shaped URL gate, walk form controls and:

  • Clear pre-populated <input type="text|email|tel|number"> values when the page state suggests pre-fill (value present without user input — detectable on initial DOM).
  • Reset <select> to its first option (or a blank option if one exists) when the default differs from the natural-first choice.
  • Reset <input type="radio"> groups to unchecked when a default is server-supplied.
  • Clear value on <input type="hidden"> whose name matches a curated affiliate/referral/promo pattern (*aff*, *ref*, *promo*, *utm_*, coupon_id, discount_code) — but only on payment/order pages.

Out of scope for v1: role="textbox" / contenteditable widgets, complex date pickers, anything inside a payment-processor iframe.

Alternatives considered
  • Bundle into checkout-checkbox-sanitize instead of a new rule. Reasonable; the toggle becomes a bigger hammer. Splitting keeps user control finer-grained because text-field clearing has higher FP risk than checkbox clearing.
  • Synthetic blur/change event after clearing. Some sites recalc totals on input events; consider v2 if sites silently re-prefill on input without it.
Controlling false positives
  • Strict URL gate. Payment/order paths only (/cart, /checkout, /basket, /bag, /payment, /order) — never login or arbitrary forms. Reuse the exact gate of cart-addon-annotate and checkout-checkbox-sanitize so the surface is identical to a rule that's already in production.
  • Hard denylist for safety-critical hidden inputs. Never clear <input type="hidden"> whose name matches CSRF/cart/session shapes: _csrf, csrf_token, authenticity_token, cart_id, order_id, session*, nonce, state, _token, anything containing signature. Failure mode here is the form silently rejecting submit, which is worse than the original dark pattern.
  • Allowlist for hidden-input clearing. Only clear hidden inputs whose name matches the affiliate/promo pattern set above. Anything outside the allowlist is preserved.
  • <select>: only reset when the default value is NOT the first option. If the first option is selected (natural default — common pattern is <option value="">Select…</option> or <option>Standard shipping</option> first), the rule does nothing. Avoids clobbering legitimate first-option defaults.
  • Timing. Run on DOMContentLoaded, before browser autofill. Browser autofill that runs after the rule is preserved — meaning the user's password manager and saved addresses still work for inputs the rule has already cleared. Document the ordering explicitly so the contract is clear.
  • Geofencing-aware select defaults. Country/state preselection based on geo is usually legitimate. Mitigation: only reset <select> when the default deviates from the first option AND the field name is in a sneaking-prone set (shipping speed, tip percent, delivery slot, donation amount, insurance plan). Don't touch country/state/region selects.
  • Per-host kill-switch. Loyalty-program checkouts where saved details reappear by design (Amazon 1-Click, Apple Pay flows) can be denylisted by host. These flows are the user's intent.
  • No-op on inputs the user has actually focused. If document.activeElement or :focus-visible matched a field at any point, skip clearing it on rescan.
  • Graceful-failure mode. The worst user-facing outcome is "I need to retype" — recoverable. Document this so a user can clearly attribute the friction to the rule and toggle it off.
Prior art / references
  • Mathur et al. (CSCW 2019), Dark Patterns at Scale.Preselection category; already cited.
  • Brignull, deceptive.designPreselection.
  • WHATWG HTML autocomplete attribute spec — informs which fields are legitimate autofill targets vs. server-pushed prefills.
  • Adjacent OSS: Consent-O-Matic sets values to opt out on consent forms — same mechanic, different intent.

Tagged Impact L–M / Complexity M.

Dominant language
TypeScript
Stars
35
Forks
4
Avg merge
4d 14h
Merged PRs (30d)
36

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from pixiebrix/agent-browser-shield

All issues in pixiebrix/agent-browser-shield

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.