Frontend-Security

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

Budibase makes it easy to ship internal tools fast. That speed is great for product teams and terrible for security if nobody stops to ask a basic question: where does this data come from, and how is it rendered? That question matters because XSS in Budibase apps usually does not come from some dramatic “hacker-only” feature. It comes from normal app-building behavior: user-generated content, dynamic bindings, custom components, markdown-ish fields, embedded HTML, and API data that gets trusted too early. ...

Cross-site scripting is still one of the easiest ways to turn a small rendering mistake into a full account takeover. If you build donation flows, event pages, admin dashboards, checkout forms, or email template editors like the kinds of features you’d expect around Humanitix, you’re handling user-controlled content constantly. That’s exactly where XSS shows up. The boring version of XSS advice is “escape output.” True, but too shallow to be useful. Real apps have rich text, markdown, embedded widgets, analytics snippets, query-string state, and legacy code that still pokes the DOM directly. That’s where teams get burned. ...

I’ve worked on enough legacy jQuery codebases to know how XSS sneaks in: not through one giant mistake, but through dozens of “harmless” shortcuts. A team I helped had a customer support dashboard built over several years. Classic jQuery app. Server-rendered shell, lots of AJAX fragments, user comments, admin notes, profile fields, search terms reflected back into the UI. Everything felt normal until a security review found stored and reflected XSS in multiple places. ...

ToolJet is great for shipping internal tools fast. That speed is also exactly why people end up shipping XSS bugs fast. I’ve seen the same pattern over and over: a team treats ToolJet like a safe abstraction layer, assumes the platform handles all rendering risks, then mixes user input into HTML, JavaScript, or query results. Now the “internal tool” is running arbitrary script in an admin’s browser. That’s still XSS. Internal apps still hold production data, admin sessions, API tokens, and enough privileges to ruin your week. ...

Carrd is deceptively simple. That’s why people get sloppy with it. You drag in text, forms, embeds, maybe a custom code block, publish, and move on. From an XSS perspective, that “simple landing page builder” can still become a script execution surface if you treat every HTML box, embed, and third-party widget like a safe sandbox. It isn’t. This guide is the practical version: where XSS shows up in Carrd, what Carrd does and doesn’t protect you from, and what to actually paste into your setup. ...

Cal.com embeds are convenient, but they also create one of my least favorite frontend security situations: third-party UI mixed with app code that was never designed for hostile input. The Cal.com script itself isn’t the usual problem. The problem is everything around it: how teams build embed URLs, how they pass prefill data, how they read query params, and how they inject user-controlled values into the page next to the widget. ...

Shopify developers often assume Liquid gives them automatic XSS protection. That assumption is where trouble starts. Liquid does help, but only in very specific contexts. The moment you move data from HTML text into attributes, JavaScript, JSON, URLs, or raw HTML blocks, the safety story changes fast. I’ve seen plenty of themes that look clean at first glance and still leave enough room for script injection through product data, metafields, cart attributes, or section settings. ...