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. ...
Trusted Types is one of the few browser security features that actually changes developer behavior in a useful way. I like it because it goes after a common failure mode in front-end code: taking strings from somewhere untrusted and shoving them into dangerous DOM APIs like innerHTML, outerHTML, insertAdjacentHTML, or eval-adjacent sinks. That is exactly how a lot of DOM XSS happens in real apps. The short version: Trusted Types turns dangerous string-based DOM injection into a type-checked operation. Instead of passing raw strings into risky sinks, you pass special objects like TrustedHTML, usually created by a policy that sanitizes or validates the content first. ...
Third-party JavaScript is one of the fastest ways to lose control of your frontend security. Analytics, chat widgets, A/B testing tools, tag managers, ad scripts, embedded dashboards — they all run with your page’s privileges unless you isolate them. If one gets compromised, your users see the blast radius, not the vendor. From the browser’s point of view, that script is your code. This is the part many teams get wrong: XSS is not only about your own unsafe innerHTML. It is also about every script you allow to execute in your origin. ...
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. ...
Coda embeds look harmless right up until someone treats them like “just a bit of HTML from a trusted tool.” That’s the trap. I worked on a content-heavy app where editors could paste Coda doc links and get rich embedded content in articles. Nice feature. Fast to ship. Also a clean path to XSS once the implementation drifted from “embed a known provider” into “render whatever comes back.” The bug wasn’t exotic. No browser zero-day, no weird parser edge case. Just a familiar chain of bad decisions: ...
Chat apps are XSS magnets. That is not a criticism of Stream Chat specifically — it is just the reality of any product that renders user-generated content in real time, across devices, often with rich formatting layered on top. If you use Stream Chat, the core question is not “does Stream escape content?” The real question is “where can my app accidentally turn safe chat data into executable code?” That distinction matters. I have seen teams assume the chat SDK is the security boundary, then quietly reintroduce XSS through custom message rendering, markdown, link previews, emoji plugins, or attachment handling. ...
Formspree is a nice shortcut when you want form handling without running your own backend. I’ve used it for contact forms, waitlists, and simple lead capture. It removes a lot of backend work, but it does not remove frontend security work. If you collect user input and then render it anywhere in your app, you can still create an XSS bug just as easily as with a custom form handler. ...
Typeform is mostly a hosted form product, which makes people assume XSS is “their problem.” That’s only half true. If you embed Typeform into your app, pass user-controlled values into hidden fields, render Typeform responses in your own admin panel, or glue it together with custom JavaScript, XSS becomes your problem fast. I’ve seen teams lock down their main app and then casually inject Typeform data into dashboards with innerHTML. That’s how you end up with a boring form turning into a stored XSS source. ...
Squarespace is one of those platforms that feels pretty safe until you add “just a little custom code.” Then it turns into the same old web app problem: if untrusted content reaches the DOM or executable JavaScript, you can still end up with XSS. The good news: Squarespace reduces a lot of the obvious risk by controlling templates, editor workflows, and hosted infrastructure. The bad news: the moment you use Code Injection, custom blocks, third-party embeds, or sloppy client-side rendering, you can punch straight through those guardrails. ...
ServiceNow is one of those platforms where people assume the framework will save them. Sometimes it does. Sometimes it absolutely does not. I’ve seen teams build solid workflows, ACLs, and integrations, then quietly ship stored XSS through a widget, a Jelly page, or a badly handled g_form.addInfoMessage() call. The dangerous part is that ServiceNow mixes platform abstractions with plain old web rendering. If user-controlled data lands in HTML, JavaScript, or the DOM without the right encoding, you still have the same browser-side problem you’d have in any other app. ...