Forms

A few years ago I helped clean up a form workflow that looked harmless on the surface: a static marketing site, a contact form powered by Getform, and a tiny “thank you” page that echoed back the user’s name. That last part was the problem. The team assumed Getform was “just handling submissions,” so they treated the returned data like trusted content. It wasn’t. A user-controlled field got pulled from the URL and dropped into the DOM with innerHTML. That turned a basic contact form into an XSS sink. ...

Cognito Forms is convenient. That’s why teams use it. You get hosted forms, calculations, workflows, payments, and embeds without building the whole stack yourself. The security catch is the same one you get with any third-party form platform: user-controlled content eventually gets displayed somewhere. If that content is rendered unsafely in a browser, you have an XSS problem. For developers, the real question usually isn’t “Does Cognito Forms have XSS?” It’s “Where can XSS happen in the way we use Cognito Forms, and which defenses are actually worth the complexity?” ...

Netlify Forms are convenient, but they create a classic security trap: teams treat form submissions like harmless content, then render them in dashboards, emails, thank-you pages, or admin tools without thinking about XSS. That’s where things go sideways. Netlify handles submission collection. It does not magically make user input safe to render as HTML. If someone submits <img src=x onerror=alert(1)>, that payload is still just attacker-controlled input. The XSS happens later, when your code inserts that input into the DOM unsafely. ...