Web-Security

FormBucket is convenient because it lets you collect form submissions without building a full backend. That convenience also creates a trap: teams treat it like a harmless inbox, then start rendering submission data in dashboards, emails, admin tools, thank-you pages, or internal review apps. That’s where XSS shows up. The problem usually isn’t FormBucket itself. The problem is what developers do with untrusted form data after it lands. If you accept name, message, company, or notes from a public form, assume every field is attacker-controlled HTML and JavaScript. If you forget that even once, you get stored XSS, reflected XSS, or DOM-based XSS depending on how you display it. ...

XSS defenses go wrong when teams treat “sanitize user input” like a single magic step. It isn’t. Different kinds of input need different handling, and some of the most common advice online is flat-out incomplete. My opinion: if you only remember one thing, remember this — validate for business rules, encode for output, and sanitize only when you intentionally allow HTML. That distinction matters because “sanitizing input” can mean wildly different things: ...

Power Apps gets sold as “low code,” which makes some teams assume “low risk.” That’s a mistake. I’ve seen Power Apps deployments where the frontend looked harmless, the data lived in Dataverse or SharePoint, and the team still shipped stored XSS because someone rendered user-controlled HTML inside an app component. The platform gives you a lot of guardrails, but the moment you start mixing user input, HTML text controls, custom pages, PCF components, embedded web resources, or data flowing in from Power Automate, you can absolutely create a mess. ...

XSS in URL parameters URL parameters are one of the most common places where XSS starts. They feel harmless because they arrive as plain text: https://example.com/search?q=shoes Then somebody reads q, drops it into the page, and now you have script execution. The vulnerable pattern is usually boring: const params = new URLSearchParams(window.location.search); const q = params.get('q'); document.getElementById('search-label').innerHTML = `Results for: ${q}`; If q is: <img src=x onerror=alert(1)> you just handed the browser executable HTML. ...

Jekyll is a static site generator, which makes people assume it’s automatically safe from XSS. That’s a bad assumption. Static output can still ship dangerous HTML and JavaScript to every visitor. If untrusted content gets into your templates, markdown, front matter, data files, or generated JSON, you can absolutely create stored XSS in a Jekyll site. The fact that the site is “just files” doesn’t help once the browser starts parsing them. ...

Excel web add-ins are just web apps wearing an Office badge. That sounds obvious, but teams forget it all the time. I’ve seen this play out the same way more than once: a team builds a task pane add-in, treats workbook data like “internal content,” renders it into the DOM, and accidentally creates a clean XSS path inside Excel. The UI looks harmless. The payload comes from a spreadsheet cell, a custom function result, or a document setting. Then somebody pastes attacker-controlled content into a workbook, shares it, and the add-in executes script in the task pane. ...

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?” ...

Server-side rendering feels safer than shipping a giant client-side app. A lot of HTML is generated on the server, templates usually escape output by default, and there is less obvious DOM manipulation in the browser. That safety is real, but people overestimate it. I’ve seen teams say “we use SSR, so XSS isn’t really a concern.” Then you look at the code and find raw HTML helpers, unquoted attributes, JSON blobs jammed into <script> tags, and a CSP that exists only in a slide deck. SSR reduces some attack surface. It does not remove the core problem: if untrusted data lands in the wrong output context without the right encoding, you still have XSS. ...

Content Security Policy nonces are one of the cleanest ways to shut down a huge class of XSS bugs without rewriting every frontend template you own. If you’ve ever inherited a server-rendered app with inline scripts sprinkled everywhere, nonces are usually the fastest path to meaningful protection. They let you keep specific inline <script> and <style> blocks while blocking attacker-injected ones. The short version: The server generates a fresh random nonce for every HTTP response That nonce goes into the CSP header The same nonce is added to trusted inline <script> or <style> tags The browser executes only the tags with the matching nonce If an attacker injects <script>alert(1)</script>, it won’t have the right nonce, so the browser refuses to run it. ...

Make is great at moving data between systems. That convenience is exactly why XSS can sneak in so easily. I’ve seen teams assume XSS is only a frontend bug. Then they wire Make into forms, CRMs, CMS tools, Slack, email builders, internal dashboards, and webhook handlers. Suddenly untrusted input is flowing through ten services, getting reformatted three times, and landing in HTML somewhere nobody reviewed carefully. That’s the real problem with XSS in Make automations: Make usually isn’t the final vulnerable layer, but it can absolutely become the delivery mechanism. ...