Frontend-Security

Webflow gets marketed like a safe visual builder, and to be fair, it does remove a lot of classic XSS footguns. If your team is comparing platforms or deciding how much trust to place in “no-code” output, that matters. But “harder to mess up” is not the same thing as “immune to XSS.” That’s the right frame for Webflow: lower default XSS exposure than hand-rolled sites or plugin-heavy CMS setups, but still very capable of shipping unsafe script behavior when developers add custom code, embeds, or untrusted content pipelines. ...

Calendly embeds look harmless. Paste a script, drop in a div, ship the feature. That’s exactly why they get teams into trouble. I’ve seen this pattern more than once: a marketing or growth team wants faster scheduling, engineering wires up Calendly, and over time the embed becomes dynamic. Someone adds query parameters for prefilled name, email, company, campaign tags, maybe even a “custom message” field pulled from the URL. Now the embed code is no longer static. It’s generating HTML or URLs from user-controlled input. ...

Paperform makes it easy to ship forms fast. That convenience is also where teams get sloppy. I’ve seen the same pattern over and over: a safe hosted form gets wrapped in unsafe frontend code, piped through insecure automations, or embedded into pages that trust user input way too much. Paperform itself isn’t the whole story. XSS usually shows up in the code around it: confirmation pages, embed wrappers, analytics hooks, custom HTML blocks, webhook consumers, and admin dashboards displaying submissions. ...

Luma event pages look simple on the surface: title, description, speaker bios, links, embeds, maybe a custom script or two. That simplicity is exactly why teams get sloppy with XSS. They assume “it’s just an event page,” then bolt on user-generated content, third-party widgets, and custom HTML until the page becomes a perfect little script execution engine. I’ve seen this pattern a lot. Event pages tend to be built fast, owned by marketing or community teams, and touched by engineers only when something breaks. That’s where XSS sneaks in. ...

SAPUI5 does a lot of the heavy lifting for output encoding, but I’ve seen teams get a false sense of safety from that. The framework helps, yes. It does not save you when you bypass its protections, render raw HTML, or trust backend data too much. If you build SAPUI5 apps, most XSS bugs come from a handful of repeat mistakes. They’re boring, predictable, and still very exploitable. Mistake #1: Assuming model data is always safe A common SAPUI5 habit is to bind model values directly into controls and assume the framework will handle everything. Often it does. But “often” is not a security strategy. ...

Stimulus feels safe at first glance. It does not ship a template engine, it nudges you toward small controllers, and most of the code you write is “just DOM code.” That last part is exactly where XSS creeps in. Stimulus does not create XSS by itself. Your controller code does. If you take untrusted data from data-* attributes, query params, server-rendered HTML fragments, or API responses and push it into dangerous DOM sinks, you have DOM XSS. Stimulus makes those flows easy to write, which means you need a clear rule set. ...

HTMX is great at making server-rendered apps feel fast without dragging in a giant frontend stack. I like it for exactly that reason. You keep your templates, keep your backend routing, and sprinkle interactivity where you need it. The catch: HTMX is built around fetching HTML and swapping it into the DOM. That’s the same territory where XSS thrives. If your app sends attacker-controlled HTML back to the browser, HTMX will happily insert it. That doesn’t make HTMX uniquely insecure. It just means the trust boundary is very clear: HTMX amplifies whatever your server returns. ...

Alpine.js feels safe because it stays close to plain HTML. That’s part of why people trust it too much. I’ve seen teams assume “small framework” means “small attack surface.” Not true. Alpine gives you powerful ways to bind data into the DOM, evaluate expressions, and react to user input. Those same features can become XSS sinks if you feed them untrusted data. If you build with Alpine, the good news is simple: most XSS issues come from a handful of dangerous patterns. Avoid those, and Alpine is pretty manageable. ...

Angular gives you better XSS defaults than most frontend frameworks. That’s the good news. The bad news: teams still break those protections all the time. I’ve seen this happen in real apps that started out safe, then picked up “just one quick workaround” for rich text, embeds, markdown, or dynamic links. A few months later, the app is full of bypassSecurityTrustHtml, direct innerHTML writes, and helper pipes that quietly turn untrusted input into executable code. ...

WeChat mini-programs look like web apps, smell like web apps, and absolutely still give teams a false sense of security around XSS. I’ve seen this mistake a lot: a team assumes “it’s not running in a normal browser, so classic XSS doesn’t really apply.” That’s the wrong mental model. The attack surface is different, the rendering model is more constrained, and some browser features are missing, but untrusted data is still untrusted data. If your mini-program renders attacker-controlled content, builds templates carelessly, or bridges unsafe data into native-like APIs, you can still end up with script injection, UI redress issues, data theft, or malicious action execution. ...