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. ...
Qwik does a lot right for security by default, but “by default” is where people get lazy. I’ve seen teams assume that because they’re using a modern framework, XSS is basically handled. Then somebody adds raw HTML rendering for a CMS snippet, builds a cute dynamic link component, or injects JSON into the page during SSR, and now the app has a very old-school bug wearing a very modern outfit. ...
v-html is one of those Vue features that feels convenient right up until it becomes a security incident. If you render untrusted HTML with v-html, you are bypassing Vue’s normal escaping protections and handing the browser raw markup. That means any unsafe HTML that survives into that string can execute script, steal session data, or manipulate the page in ways you did not expect. For a developer audience, the rule is simple: ...
DOM clobbering is one of those bugs frontend teams accidentally create while thinking they are dealing with “just HTML”. Then it turns into script execution, broken security assumptions, or both. The short version: browsers expose some elements with id or name values as properties on global objects like window and sometimes on forms. If your JavaScript trusts those properties, an attacker can inject markup that overwrites what your code thinks is a safe variable, config object, or URL. That often becomes XSS. ...
Magento gives you plenty of ways to shoot yourself in the foot with XSS. That’s not a Magento-only problem. Any platform with PHP templates, admin-managed content, third-party modules, Knockout bindings, and a lot of custom theme work is going to collect XSS bugs like dust. Magento just makes it easy to hide them in places that look harmless during code review. If you build or maintain Magento stores, these are the mistakes I see most often, and how I’d fix them without turning every template into a mess. ...