Among 500 Top Domains, 0% of Assessed Contact Forms Met Our Full Security Standard
2026 contact-form security study
0 of 20 unique contact-form implementations met every observable control in our full standard. This is a strict “demonstrated secure” result, not proof that every form is exploitable.
Change the definition and inspect the result
These buttons change how strict the word “secure” is. The strictest definition requires every public signal we could check. The loosest definition only checks whether the form appears to submit safely.
The form showed every public sign we would want before calling it secure: safe submission, no other-domain scripts in the form, no early data transmission, minimal required identity, browser guardrails, retention clarity, and browser-side or end-to-end encryption evidence.
Legend: what the terms mean
A form submission method that puts submitted values in the request body.
This is safer than GET for sensitive text because GET can put values in the URL, where they can appear in browser history, server logs, referrer headers, analytics, and screenshots.
The URL the browser sends the form to after someone clicks send.
A page can be HTTPS while the form points somewhere else. We checked the page and the destination separately.
JavaScript loaded from a different registrable domain while the form is on screen.
If that script runs in the same frame as the textarea, it can technically read what a person types.
A network request containing a synthetic value after typing but before clicking send.
The user has not consented to submit yet. In this run, we saw one cross-site pre-submit leak: an email value sent to a HubSpot email-check endpoint.
Content Security Policy, a browser rule set sent by the site.
`form-action` limits where the form may submit. `frame-ancestors` limits who may embed the page.
Public evidence that the message is encrypted in the browser to the recipient, not just protected by HTTPS on the way to the server.
HTTPS does not prove the server stores ciphertext or that staff, vendors, logs, or backups cannot read the message.
Control-by-control results
Each row below is a yes/no control. A passing count means the control was visible from the browser during this run, not that the site passed a private architecture review.
What the data says for each control
Only 11 forms passed all three basic route checks: HTTPS page, HTTPS destination, and POST.
Nine forms used GET or a JavaScript-only action. We did not submit the forms, so this is a route-quality finding, not proof that any user data was actually placed in a URL during our run.
Nineteen forms loaded at least one other-domain script in the same frame as the form.
Examples included Google Tag Manager, HubSpot, Marketo, Adobe, Yandex, New Relic, PostHog, Trustpilot, LiveChat, Microsoft CDN hosts, and bot/captcha services. One form, GOV.UK, had zero other-domain scripts in the form frame.
One form transmitted a synthetic value before the user clicked send.
MediaTek sent the synthetic email field to `forms.hsforms.com/emailcheck/v1/json-ext` using an XHR POST request. We did not observe the synthetic message body, name, or phone number sent cross-site before submit.
Three forms required high-risk identity fields such as phone number, business email, company, or detailed business profiling.
This matters because the safest sensitive-intake path should let someone ask for help without first disclosing more identity than the task requires.
Only two forms locked the submit destination with CSP `form-action`; thirteen limited framing with `frame-ancestors`.
These headers are not encryption. They are defense-in-depth rules that reduce the blast radius of mistakes, injected code, and unauthorized embedding.
Only three forms surfaced retention or deletion language on the assessed page.
A privacy link in the footer is not the same as telling a sensitive sender how long the message persists, who can access it, and how deletion works.
No assessed form published specific browser-side or end-to-end encryption evidence.
The test cannot prove plaintext storage from the outside. It can show whether the page gives a sender evidence that plaintext will not be readable by the receiving server or its vendors.
Explore every assessed implementation
“Pass” means that specific control was visible and satisfied in the browser. “No” means the control was missing or not demonstrated. For early data transmission, “Pass” means our synthetic values were not observed in cross-site requests before submit.
20 implementations shown.
| Rank / domain | Submission route | Other-domain scripts | Typed data sent early | Required identity | Browser guardrails | Retention explained | Encryption evidence | Full |
|---|---|---|---|---|---|---|---|---|
| #45 skype.com observed form | Protected submission route: does not passAt least one route check failed. | 22 other-domain hosts could access the form frame. | No observed pre-submit cross-site leak: passesNo synthetic value observed cross-site before submit. | No required high-risk identity: passesNo high-risk identity field was required. | CSP form and frame restrictions: does not passMissing form-action, frame-ancestors, or both. | Retention disclosure: does not passNo form-specific lifecycle language found. | E2EE evidence: does not passNo browser-side or E2EE evidence found. | Full observable standard: does not pass |
| #6 microsoft.com observed form | Protected submission route: does not passAt least one route check failed. | 33 other-domain hosts could access the form frame. | No observed pre-submit cross-site leak: passesNo synthetic value observed cross-site before submit. | No required high-risk identity: passesNo high-risk identity field was required. | CSP form and frame restrictions: does not passMissing form-action, frame-ancestors, or both. | Retention disclosure: does not passNo form-specific lifecycle language found. | E2EE evidence: does not passNo browser-side or E2EE evidence found. | Full observable standard: does not pass |
| #88 workers.dev observed form | Protected submission route: does not passAt least one route check failed. | 77 other-domain hosts could access the form frame. | No observed pre-submit cross-site leak: passesNo synthetic value observed cross-site before submit. | No required high-risk identity: does not passRequired phone or detailed business identity. | CSP form and frame restrictions: passesCSP locked both submit destination and embedding. | Retention disclosure: does not passNo form-specific lifecycle language found. | E2EE evidence: does not passNo browser-side or E2EE evidence found. | Full observable standard: does not pass |
| #116 b-cdn.net observed form | Protected submission route: does not passAt least one route check failed. | 22 other-domain hosts could access the form frame. | No observed pre-submit cross-site leak: passesNo synthetic value observed cross-site before submit. | No required high-risk identity: passesNo high-risk identity field was required. | CSP form and frame restrictions: does not passMissing form-action, frame-ancestors, or both. | Retention disclosure: does not passNo form-specific lifecycle language found. | E2EE evidence: does not passNo browser-side or E2EE evidence found. | Full observable standard: does not pass |
| #190 cnn.com observed form | Protected submission route: does not passAt least one route check failed. | 44 other-domain hosts could access the form frame. | No observed pre-submit cross-site leak: passesNo synthetic value observed cross-site before submit. | No required high-risk identity: passesNo high-risk identity field was required. | CSP form and frame restrictions: does not passMissing form-action, frame-ancestors, or both. | Retention disclosure: passesLifecycle language found on the assessed page. | E2EE evidence: does not passNo browser-side or E2EE evidence found. | Full observable standard: does not pass |
| #230 nist.gov observed form | Protected submission route: passesHTTPS page + HTTPS destination + POST. | 44 other-domain hosts could access the form frame. | No observed pre-submit cross-site leak: passesNo synthetic value observed cross-site before submit. | No required high-risk identity: passesNo high-risk identity field was required. | CSP form and frame restrictions: does not passMissing form-action, frame-ancestors, or both. | Retention disclosure: does not passNo form-specific lifecycle language found. | E2EE evidence: does not passNo browser-side or E2EE evidence found. | Full observable standard: does not pass |
| #234 ubuntu.com observed form | Protected submission route: passesHTTPS page + HTTPS destination + POST. | 22 other-domain hosts could access the form frame. | No observed pre-submit cross-site leak: passesNo synthetic value observed cross-site before submit. | No required high-risk identity: passesNo high-risk identity field was required. | CSP form and frame restrictions: does not passMissing form-action, frame-ancestors, or both. | Retention disclosure: does not passNo form-specific lifecycle language found. | E2EE evidence: does not passNo browser-side or E2EE evidence found. | Full observable standard: does not pass |
| #240 stripe.com observed form | Protected submission route: passesHTTPS page + HTTPS destination + POST. | 11 other-domain host could access the form frame. | No observed pre-submit cross-site leak: passesNo synthetic value observed cross-site before submit. | No required high-risk identity: does not passRequired phone or detailed business identity. | CSP form and frame restrictions: passesCSP locked both submit destination and embedding. | Retention disclosure: does not passNo form-specific lifecycle language found. | E2EE evidence: does not passNo browser-side or E2EE evidence found. | Full observable standard: does not pass |
| #245 meraki.com observed form | Protected submission route: passesHTTPS page + HTTPS destination + POST. | 33 other-domain hosts could access the form frame. | No observed pre-submit cross-site leak: passesNo synthetic value observed cross-site before submit. | No required high-risk identity: passesNo high-risk identity field was required. | CSP form and frame restrictions: does not passMissing form-action, frame-ancestors, or both. | Retention disclosure: does not passNo form-specific lifecycle language found. | E2EE evidence: does not passNo browser-side or E2EE evidence found. | Full observable standard: does not pass |
| #292 www.gov.uk observed form | Protected submission route: passesHTTPS page + HTTPS destination + POST. | 0No other-domain scripts observed in the form frame. | No observed pre-submit cross-site leak: passesNo synthetic value observed cross-site before submit. | No required high-risk identity: passesNo high-risk identity field was required. | CSP form and frame restrictions: does not passMissing form-action, frame-ancestors, or both. | Retention disclosure: does not passNo form-specific lifecycle language found. | E2EE evidence: does not passNo browser-side or E2EE evidence found. | Full observable standard: does not pass |
| #358 quickconnect.to observed form | Protected submission route: passesHTTPS page + HTTPS destination + POST. | 22 other-domain hosts could access the form frame. | No observed pre-submit cross-site leak: passesNo synthetic value observed cross-site before submit. | No required high-risk identity: passesNo high-risk identity field was required. | CSP form and frame restrictions: does not passMissing form-action, frame-ancestors, or both. | Retention disclosure: passesLifecycle language found on the assessed page. | E2EE evidence: does not passNo browser-side or E2EE evidence found. | Full observable standard: does not pass |
| #364 selectel.ru observed form | Protected submission route: does not passAt least one route check failed. | 11 other-domain host could access the form frame. | No observed pre-submit cross-site leak: passesNo synthetic value observed cross-site before submit. | No required high-risk identity: passesNo high-risk identity field was required. | CSP form and frame restrictions: does not passMissing form-action, frame-ancestors, or both. | Retention disclosure: does not passNo form-specific lifecycle language found. | E2EE evidence: does not passNo browser-side or E2EE evidence found. | Full observable standard: does not pass |
| #381 plesk.com observed form | Protected submission route: passesHTTPS page + HTTPS destination + POST. | 22 other-domain hosts could access the form frame. | No observed pre-submit cross-site leak: passesNo synthetic value observed cross-site before submit. | No required high-risk identity: passesNo high-risk identity field was required. | CSP form and frame restrictions: does not passMissing form-action, frame-ancestors, or both. | Retention disclosure: does not passNo form-specific lifecycle language found. | E2EE evidence: does not passNo browser-side or E2EE evidence found. | Full observable standard: does not pass |
| #385 tp-link.com observed form | Protected submission route: passesHTTPS page + HTTPS destination + POST. | 33 other-domain hosts could access the form frame. | No observed pre-submit cross-site leak: passesNo synthetic value observed cross-site before submit. | No required high-risk identity: passesNo high-risk identity field was required. | CSP form and frame restrictions: does not passMissing form-action, frame-ancestors, or both. | Retention disclosure: does not passNo form-specific lifecycle language found. | E2EE evidence: does not passNo browser-side or E2EE evidence found. | Full observable standard: does not pass |
| #400 zendesk.com observed form | Protected submission route: does not passAt least one route check failed. | 22 other-domain hosts could access the form frame. | No observed pre-submit cross-site leak: passesNo synthetic value observed cross-site before submit. | No required high-risk identity: passesNo high-risk identity field was required. | CSP form and frame restrictions: does not passMissing form-action, frame-ancestors, or both. | Retention disclosure: passesLifecycle language found on the assessed page. | E2EE evidence: does not passNo browser-side or E2EE evidence found. | Full observable standard: does not pass |
| #410 cloudns.net observed form | Protected submission route: passesHTTPS page + HTTPS destination + POST. | 22 other-domain hosts could access the form frame. | No observed pre-submit cross-site leak: passesNo synthetic value observed cross-site before submit. | No required high-risk identity: passesNo high-risk identity field was required. | CSP form and frame restrictions: does not passMissing form-action, frame-ancestors, or both. | Retention disclosure: does not passNo form-specific lifecycle language found. | E2EE evidence: does not passNo browser-side or E2EE evidence found. | Full observable standard: does not pass |
| #414 netangels.ru observed form | Protected submission route: does not passAt least one route check failed. | 44 other-domain hosts could access the form frame. | No observed pre-submit cross-site leak: passesNo synthetic value observed cross-site before submit. | No required high-risk identity: passesNo high-risk identity field was required. | CSP form and frame restrictions: does not passMissing form-action, frame-ancestors, or both. | Retention disclosure: does not passNo form-specific lifecycle language found. | E2EE evidence: does not passNo browser-side or E2EE evidence found. | Full observable standard: does not pass |
| #429 steamcommunity.com observed form | Protected submission route: does not passAt least one route check failed. | 22 other-domain hosts could access the form frame. | No observed pre-submit cross-site leak: passesNo synthetic value observed cross-site before submit. | No required high-risk identity: passesNo high-risk identity field was required. | CSP form and frame restrictions: does not passMissing form-action, frame-ancestors, or both. | Retention disclosure: does not passNo form-specific lifecycle language found. | E2EE evidence: does not passNo browser-side or E2EE evidence found. | Full observable standard: does not pass |
| #481 mediatek.com observed form | Protected submission route: passesHTTPS page + HTTPS destination + POST. | 88 other-domain hosts could access the form frame. | No observed pre-submit cross-site leak: does not passSynthetic email sent to forms.hsforms.com before submit. | No required high-risk identity: passesNo high-risk identity field was required. | CSP form and frame restrictions: does not passMissing form-action, frame-ancestors, or both. | Retention disclosure: does not passNo form-specific lifecycle language found. | E2EE evidence: does not passNo browser-side or E2EE evidence found. | Full observable standard: does not pass |
| #491 paloaltonetworks.com observed form | Protected submission route: passesHTTPS page + HTTPS destination + POST. | 66 other-domain hosts could access the form frame. | No observed pre-submit cross-site leak: passesNo synthetic value observed cross-site before submit. | No required high-risk identity: does not passRequired phone or detailed business identity. | CSP form and frame restrictions: does not passMissing form-action, frame-ancestors, or both. | Retention disclosure: does not passNo form-specific lifecycle language found. | E2EE evidence: does not passNo browser-side or E2EE evidence found. | Full observable standard: does not pass |
The short answer is stark: 0% of the contact-form implementations we could assess demonstrated every control in our observable security standard.
The practical answer is more specific: most forms were not failing one exotic cryptography test. They were failing ordinary intake hygiene that a non-expert can understand.
- 19 of 20 forms gave other-domain JavaScript access to the form frame. This does not prove those scripts collected the message, but it means they had the technical position to read what a person typed.
- 9 of 20 forms failed the full submission-route check. Every form page used
HTTPS, but only 11 also submitted to an HTTPS destination with
POST. - 1 of 20 forms sent typed data before submit. MediaTek’s form sent the
synthetic email address to HubSpot’s
forms.hsforms.com/emailcheck/v1/json-extendpoint before we clicked send. We did not observe the synthetic message body, name, or phone number sent cross-site before submit. - 17 of 20 forms avoided required high-risk identity fields. Three required fields such as phone number or detailed business identity before a user could complete the form.
- 0 of 20 forms published specific evidence of browser-side or end-to-end message encryption. HTTPS is useful, but it does not prove ciphertext storage or recipient-only access.
- 3 of 20 forms surfaced retention or deletion language on the assessed page.
What “secure” means in this study
“Secure” is often used as a synonym for “served over HTTPS.” That is too weak for a form that may receive reports about abuse, legal problems, workplace retaliation, security vulnerabilities, health, finances, or identity.
We counted a form as meeting the full observable standard only when every one of these controls was demonstrated:
| Plain-English control | Passing condition | What failure communicates |
|---|---|---|
| Protected submission route | The page used HTTPS, the submit destination used HTTPS, and the form used POST | The form may still work, but it did not show the basic route pattern expected for sensitive text |
| Input isolation | No scripts from another registrable domain executed in the form’s frame | Other-domain code had technical access to the fields |
| No typed data sent early | Synthetic message, email, name, and phone canaries were not observed in cross-site requests before submission | A value moved before the user clicked send |
| Data minimization | Phone, address, account identifier, or similarly high-risk identity fields were not mandatory | The form demanded more identity than sensitive intake should require by default |
| Browser guardrails | CSP included both form-action and frame-ancestors | The site did not ask the browser to enforce where forms may submit or who may embed the form |
| Lifecycle transparency | Retention or deletion handling was disclosed on the assessed page | The sender cannot see how long the message persists or who may access it |
| Message confidentiality | The page published specific browser-side or end-to-end encryption evidence | HTTPS protects transport only; it does not prove encrypted storage or recipient-only access |
This is intentionally a demonstrated-security standard. A form that did not pass is not automatically vulnerable. It means the form did not expose enough observable evidence for us to classify it as secure under this threat model.
In other words, “secure” here does not mean “we found no exploit.” It means “a reasonable sender can see enough evidence, in the browser, to trust this as a sensitive intake surface.”
What actually leaked
We observed one cross-site pre-submit leak.
The form was on mediatek.com. After the test typed a synthetic email address,
the browser sent that email value to:
host: forms.hsforms.com
path: /emailcheck/v1/json-ext
method: POST
resource type: XHR
matched field type: email
timing: before submit
We did not observe the synthetic message body, name, or phone number sent to a cross-site host before submit. That distinction matters. The strongest finding is not “every form leaked typed content during this test.” The stronger, reproducible finding is that most forms allowed unnecessary access paths, and one form converted that access into an observed early transmission.
The most common exposure was not an observed leak; it was script access. In 19 of 20 forms, code from another registrable domain executed in the same frame as the form. Examples included Google Tag Manager, HubSpot, Marketo, Adobe, Yandex, New Relic, PostHog, Trustpilot, LiveChat, Microsoft CDN hosts, and bot/captcha services. Some of those services may be legitimate operational dependencies. The point is narrower: if a script runs in the form frame, it is in the trust boundary for that form.
The standard draws on the W3C Privacy Principles, especially data minimization, transparency, purpose limitation, and sensitive-information handling. The cross-site script criterion reflects OWASP’s warning that third-party JavaScript can disclose sensitive DOM data. The CSP checks use the defense-in-depth guidance in the OWASP Content Security Policy Cheat Sheet.
What we can and cannot prove from outside
The original hypothesis included plaintext storage and unnecessary server logs. Those are important questions, but a public browser crawl cannot directly answer them.
We can observe:
- whether the page and submit destination used HTTPS
- whether the form used POST or GET
- other-domain script origins running in the form frame
- field requirements
- response security headers
- pre-submit browser requests containing synthetic values
- public claims about retention and end-to-end encryption
We cannot observe:
- whether the receiving server logs request bodies
- whether application databases store plaintext
- who can access internal dashboards or backups
- whether published retention promises are followed operationally
- whether a non-public encryption control exists
For those controls, the right follow-up is an evidence request: architecture, data-flow diagrams, retention schedules, access-control policy, audit logs, and independent testing. We did not convert “unknown” into “insecure,” but unknown also did not qualify as demonstrated secure.
Methodology
We used the top 500 pay-level domains from Tranco list XLPJN, generated on June 7, 2026 from 30 days of ranking inputs. Tranco is designed for reproducible web measurement and provides permanent references for historical lists.
The crawl ran on June 8, 2026:
- Request the HTTPS homepage, falling back to HTTP only when HTTPS navigation failed.
- Inspect the homepage and at most one highest-scoring contact, support, feedback, help, report, or tip link.
- Require a rendered form with a substantive non-CAPTCHA textarea.
- Render candidate pages in headless Chrome and inspect every frame.
- Record scripts executing in the same frame as the form.
- Fill eligible fields with clearly synthetic values under
example.com, dispatch normal input/change/blur events, and watch requests for 3.5 seconds. - Never click submit, never send a form, and never solve or bypass a CAPTCHA.
- Deduplicate identical form implementations reached through multiple ranked domains.
- Manually review every assessed implementation and remove search, CAPTCHA-only, honeypot-only, and failed-render false positives.
Of 500 ranked domains, 261 returned a reachable homepage in this run. The crawl found 24 ranked-domain instances representing 20 unique form implementations. The high attrition is expected because Tranco includes infrastructure domains, CDNs, APIs, redirectors, and sites that block automated browsers. Therefore the headline denominator is 20 assessed implementations, not all 500 domains.
Raw data you can audit
The complete redacted output is available as JSON data, an assessed-implementations CSV, and the fixed top-500 ranking snapshot CSV. The study runner and fixed ranking snapshot are included in the documentation repository.
The exact fields behind the headline claims are:
| Claim in article | Raw field or derivation |
|---|---|
| 500 ranked domains screened | metadata.ranking.rankRange and the Tranco input CSV |
| 261 reachable homepages | summary.reachableHomepages |
| 20 unique implementations assessed | CSV row count, or JSON records where score.assessed is true deduped by formFingerprint |
| 0 passed the full observable standard | full_observable_standard in CSV, or score.secure in JSON |
| 11 passed protected transport | protected_transport_tier in CSV, or score.baselineTransport in JSON |
| 19 loaded other-domain scripts | no_third_party_scripts=false in CSV, or score.criteria.noThirdPartyScripts=false in JSON |
| 1 sent typed data to a cross-site processor before submit | leaked_before_submit=true, third_party_canary_hosts, and canary_request_details in CSV, or browserCheck.leakedBeforeSubmit=true in JSON |
| 0 published browser-side or E2EE evidence | encryption_disclosed=false in CSV, or score.criteria.encryptionDisclosed=false in JSON |
For example, a reviewer can reproduce the strict headline from the CSV by
counting rows where full_observable_standard is true; the answer is zero.
The MediaTek pre-submit finding is the one row where leaked_before_submit is
true, with the redacted request recorded as:
POST forms.hsforms.com/emailcheck/v1/json-ext XHR matched=email
The CSV also includes canary_request_count and canary_hosts. Those fields
show any request containing a synthetic value after input, including same-party
validation requests. The leak claim uses the narrower leaked_before_submit
boolean and third_party_canary_hosts field, which require a synthetic value to
move to a different registrable domain before the form was submitted.
This evidence still has limits. It supports claims about what a browser could observe during this run. It does not prove internal plaintext storage, server logging, access-control policy, or retention enforcement.
What engineering teams should change
1. Isolate the sensitive form
Do not place a sensitive textarea in the same document as advertising, session-replay, marketing automation, A/B testing, or broad tag-manager code. Use a dedicated form document with a minimal script set. A sandboxed cross-origin iframe can prevent scripts in the parent page from reading the form.
2. Treat cross-site JavaScript as privileged access
An analytics script does not need to exfiltrate a canary during this test to be a risk. If it executes in the form frame, it can read the DOM. Inventory every script origin, identify its owner and purpose, and remove it unless it is necessary for the submission.
3. Add explicit CSP controls
At minimum, constrain where the form may submit and who may frame it:
Content-Security-Policy:
default-src 'self';
script-src 'self';
connect-src 'self';
form-action 'self';
frame-ancestors 'self' https://approved.example;
Real deployments may need additional exact origins, but broad wildcards and marketing domains should not be inherited by a sensitive intake surface.
4. Make identity optional by default
A reply address can be useful, but it should not be confused with a security requirement. Ask only for fields necessary to complete the user’s stated task. For high-risk reporting, anonymous submission should be a first-class path.
5. Encrypt for the recipient before transmission
TLS protects the hop to the web server. It does not stop that server, its logs, its database operators, or a compromised application from reading plaintext. For sensitive intake, encrypt the message in the browser to a recipient-held key and fail closed if encryption cannot be completed.
6. Publish the data lifecycle
State what is collected, whether metadata is minimized, where ciphertext or plaintext is stored, who can access it, how long it is retained, and how it is deleted. A generic footer privacy link is not a substitute for form-specific handling information.
What this means for Hush Line embeds
The study supports the product premise behind Hush Line’s embeddable forms, but the comparison should be stated in measurable terms.
For sensitive intake, the most important question is not “does the page have a contact form?” It is whether the form keeps the sender away from the host site’s marketing stack, avoids early data sharing, and encrypts the message for the recipient before it becomes ordinary web-app data.
Using that narrower core sensitive-intake definition, the comparison is:
| Core sensitive-intake control | Best observed among assessed forms | Hush Line embed evidence | Result |
|---|---|---|---|
| Protected submission route | 11 of 20 used HTTPS page + HTTPS destination + POST | Hush Line embed form uses method="POST" and same-app submit route | Hush Line matches the best observed route pattern |
| Keep host-page scripts away from the message fields | 1 of 20 had zero other-domain scripts in the form frame | Hush Line places the intake form in a sandboxed iframe and the embed template loads Hush Line-owned scripts, not the host page’s analytics scripts | Hush Line is designed for isolation, not co-location |
| Do not send typed values before submit | 19 of 20 had no observed cross-site canary leak; 1 sent the synthetic email to HubSpot before submit | Hush Line’s embed has no third-party form processor in the template and uses recipient encryption before final submission when JavaScript is available | Hush Line removes the observed leak class from the form architecture |
| Require only necessary identity | 17 of 20 did not require high-risk identity fields | Hush Line fields are recipient-configurable and can be deployed without required phone, company, or business identity fields | Hush Line can preserve anonymous intake; deployers must keep it configured that way |
| Encrypt the message for the recipient | 0 of 20 published browser-side or end-to-end encryption evidence | Hush Line labels encryption state, loads recipient public keys, encrypts configured fields in the browser, and blocks eligible embeds when the recipient lacks a usable key | Hush Line has the clearest measurable advantage |
That gives a reproducible comparison:
- 0 of 20 assessed forms passed the combined core set of protected route, no other-domain form-frame scripts, no observed early cross-site canary, and browser-side or end-to-end encryption evidence.
- Hush Line embeds have implementation evidence for that core set when the recipient has a usable key and the deployer keeps identity fields optional.
- The two Hush Line follow-ups identified by the full rubric are not architectural equivalents of the common contact-form failures. They are explicit, observable hardening and disclosure controls that Hush Line now includes.
Objective takeaway: Hush Line is the best choice in this comparison for sensitive intake because it is the only evaluated option with a purpose-built isolated embed, recipient-key encryption evidence, no dependence on the host page’s marketing scripts, an explicit form submission destination policy, and form-specific privacy and retention disclosure.
The precise public claim is:
Hush Line gives organizations an isolated, recipient-encrypted intake form that addresses the biggest observable failures found in popular-site contact forms. In this study, no assessed conventional contact-form implementation demonstrated the same combination of iframe isolation, recipient-side encryption evidence, explicit form destination controls, and form-specific privacy and retention disclosure.
The current Hush Line embed implementation:
- places the form in a
sandboxed iframe
with
referrerpolicy="no-referrer" - requires exact allowed parent origins
- uses an HTTPS POST form
- labels encryption state in the embedded form
- encrypts configured fields in the browser to recipient public keys
- blocks eligible embeds when the recipient lacks a usable encryption key
- applies an explicit
form-actionCSP directive - shows a concise retention and privacy explanation inside the embed
Those statements are reproducible from the linked implementation:
- iframe sandboxing and
referrerpolicy="no-referrer"are generated in hushline/embeds.py - exact embed origins are normalized and reject wildcards in hushline/model/username.py
- the embed form, encryption badge, recipient public-key payload, and POST route are rendered in hushline/templates/embed_profile.html
- browser-side encryption is implemented in hushline/static/js/client-side-encryption.js
- embed-specific
frame-ancestorshandling and theform-actiondirective are applied in hushline/init.py - the embed privacy and retention explanation is rendered in hushline/templates/embed_profile.html
Applying the full rubric to our own implementation still produced two concrete hardening requirements. Hush Line now covers both:
- It applies an explicit
form-actiondirective to the Hush Line CSP. - It surfaces a concise, linked retention and privacy explanation inside the embed.
That means the defensible value proposition is stronger and simpler: Hush Line provides an isolated, recipient-encrypted intake component that replaces the riskiest parts of a typical contact-form stack and satisfies the observable sensitive-intake controls used in this study when recipient encryption is configured.
Conclusion
The experiment supports the core hypothesis, with an important qualification. We did not prove that most contact forms store plaintext or log message bodies. We did find that the observable security posture of popular-site contact forms is weak:
- none demonstrated the full standard
- almost every form shared a frame with cross-site JavaScript
- only about half showed a protected submission route
- retention information was uncommon
- none published specific end-to-end encryption evidence
That is enough to make contact-form security a measurable product category rather than a vague assertion. It also gives engineering teams a concrete checklist and gives Hush Line a value proposition grounded in reproducible data, not fear.