Hardening pass: input validation, origin checks, and default-safe field behaviour — main (v3-alpha)

[shengxi-gt]

Hardening pass — main (v3-alpha)

Covers several hardening changes and default-safe behaviour updates across fields and shared utilities. One commit — review the diff directly since the changes span multiple independent areas with varying blast radius.

⚠️ Breaking changes

Four changes alter default runtime behaviour unconditionally, no opt-out, for every existing schema as soon as this ships:

1. Iframe postMessage origin check is now hard default-on. Messages from a mismatched origin are silently dropped.
2. 1000-character cap on schema-authored regex input. Inputs longer than 1000 chars are treated as non-matching regardless of the actual pattern result. Affects matches, notMatches, and filenameMatches rules.
3. MaskedField maxLength now defaults to 1000 whenever maskRegex is set and no max/length rule already narrows it.
4. Pattern strings not wrapped in /pattern/flags slashes are no longer silently skipped. They previously landed in a catch block and validation was skipped entirely (value always passed). The shared parsing helper now falls back to treating the whole string as a raw pattern and applies it — any schema relying on the old silent no-op will now get real validation applied.

Narrower breaking changes (only affect a consumer that relied on the specific permissive behaviour being fixed):

• sanitize-html configuration: stricter attribute allowlist may now strip attributes that previously passed through unsanitized.
• ButtonField URL scheme check: links using a non-standard scheme (e.g. custom app deep-links) will now be blocked.
• locationModalStyles / imageReviewModalStyles: url() and @import are now stripped from these CSS strings before they are applied to the modal box. Any background image or external resource passed via these props will silently stop working. Verified against all known consumers — none currently use these props with url() or @import.

Changes covered

• CI pipeline configuration hardened
• sanitize-html configuration tightened in Typography, FilterCheckbox, Popover
• ButtonField link URLs now restricted to http/https/tel/mailto schemes
• Iframe postMessage now validates origin by default
• Location-field search query now escaped before use in RegExp
• OTP state field documented as client-asserted (no code change)
• Schema regex inputs now capped at 1000 characters
• MaskedField maxLength defaults to 1000 when maskRegex is set
• Shared regex parsing helper introduced; unwrapped patterns now evaluated instead of silently skipped
• Custom modal style strings now strip @import and url() references
• locationModalStyles and imageReviewModalStyles prop descriptions updated in Storybook
• ImageUpload matches rule no longer blocks valid submissions (pre-existing bug fix)
• Playwright e2e dev-server configuration hardened

Test plan

• Full Jest suite + eslint + tsc --noEmit pass on this branch.
• Each change was individually verified at the time it was written.

[shengxi-gt]

jest just seems to hang indefinitely on this test case, this time check doesn't seem useful

You were right that the old version hung — the query was passed directly to new RegExp() without escaping. In this PR we added escapeRegExp(query) before building the RegExp (line 12 of helper.ts), so (a+)+$ becomes the literal pattern \(a\+\)\+\$. No backtracking; the test completes in microseconds. We also moved the spec file to the location-modal/location-search/ subdirectory as part of the reorganisation.

[shengxi-gt]

would argue against this change, the value are provided by the client/server in the first place

The concern isn't distrust of the originating server — it's that between the server delivering the prefilled payload and the browser submitting the form, the data lives in the page where a user (or MITM proxy) can modify it. The frontend can verify files it fetches (fileUrl) or encodes itself (dataURL), but for a prefilled file with neither field it has no independent signal to validate mimeType/ext/fileSize against. Defaulting trustProvidedFileMetadata: false means: we don't silently present unverifiable metadata as trusted. Consumers that control their own pipeline and accept that trade-off can opt in with true.

[qroll]

would argue against this change, the value are provided by the client/server in the first place

The concern isn't distrust of the originating server — it's that between the server delivering the prefilled payload and the browser submitting the form, the data lives in the page where a user (or MITM proxy) can modify it. The frontend can verify files it fetches (fileUrl) or encodes itself (dataURL), but for a prefilled file with neither field it has no independent signal to validate mimeType/ext/fileSize against. Defaulting trustProvidedFileMetadata: false means: we don't silently present unverifiable metadata as trusted. Consumers that control their own pipeline and accept that trade-off can opt in with true.

trustProvidedFileMetadata: if we're looking at prefilled data flow, fileUrl and dataURL also come from the same "server", what makes uploadResponse less trustworhty?

allowedFileOrigins: and then back to trusting fileUrl, shouldn't CSP connect-src help with restricting what origins are callable?

[qroll]

jest just seems to hang indefinitely on this test case, this time check doesn't seem useful

You were right that the old version hung — the query was passed directly to new RegExp() without escaping. In this PR we added escapeRegExp(query) before building the RegExp (line 12 of helper.ts), so (a+)+$ becomes the literal pattern \(a\+\)\+\$. No backtracking; the test completes in microseconds. We also moved the spec file to the location-modal/location-search/ subdirectory as part of the reorganisation.

sorry what I meant was that without the fix, the test would hang instead of timing out. how can we make jest recover from this?

[shengxi-gt]

would argue against this change, the value are provided by the client/server in the first place

The concern isn't distrust of the originating server — it's that between the server delivering the prefilled payload and the browser submitting the form, the data lives in the page where a user (or MITM proxy) can modify it. The frontend can verify files it fetches (fileUrl) or encodes itself (dataURL), but for a prefilled file with neither field it has no independent signal to validate mimeType/ext/fileSize against. Defaulting trustProvidedFileMetadata: false means: we don't silently present unverifiable metadata as trusted. Consumers that control their own pipeline and accept that trade-off can opt in with true.

trustProvidedFileMetadata: if we're looking at prefilled data flow, fileUrl and dataURL also come from the same "server", what makes uploadResponse less trustworhty?

allowedFileOrigins: and then back to trusting fileUrl, shouldn't CSP connect-src help with restricting what origins are callable?

trustProvidedFileMetadata: Actually now that i think about it more, validating this should always be server-side anyways as we should always regard the browser as an untrusted environment. So this feature actually just increases friction without really achieving what it was intended for. Hence will remove it.

allowedFileOrigins: Point taken, will add a note to use CSP connect-src instead of building redundancy. Will remove to reduce upgrade friction.

[shengxi-gt]

sorry what I meant was that without the fix, the test would hang instead of timing out. how can we make jest recover from this?

we could try using vm.runInNewContext in this context for the test?

[qroll]

the unit tests are stuck when I run them locally. do you encounter this too?