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. ...
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. ...
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. ...
Cross-site scripting in PHP usually happens because someone escaped the wrong thing, in the wrong place, at the wrong time. I’ve seen teams add htmlspecialchars() everywhere and still ship XSS. Not because the function is bad, but because XSS prevention is context-sensitive. A value that is safe in HTML text is not automatically safe in an attribute, a JavaScript string, or a URL. If you remember one rule, make it this one: ...
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. ...
Cross-site scripting in Basin usually shows up the same way it does everywhere else: user-controlled data gets treated like HTML, JavaScript, or a URL in the browser. Basin doesn’t magically create XSS, but it can absolutely become the place where unsafe input is collected, stored, and later rendered back into your app. If you use Basin for forms, contact submissions, comments, support requests, or admin dashboards, you need to assume every field is hostile. Name, email, subject, message, hidden inputs, query params copied into forms — all of it. ...
Airtable embeds feel harmless. Paste an iframe, ship the feature, move on. That’s exactly why they deserve scrutiny. If you embed Airtable views, forms, or shared interfaces into your app, you’re pulling third-party content into a trusted page. That doesn’t automatically mean “instant XSS,” because iframes do create a boundary. But I’ve seen teams treat that boundary as stronger than it really is, then poke holes in it with permissive sandbox settings, weak CSP, sloppy postMessage handlers, or custom wrappers that turn untrusted data into DOM. ...
Inline scripts are one of the easiest ways to accidentally punch a hole through your XSS defenses. If you allow <script> blocks or inline event handlers without strict controls, an attacker only needs one HTML injection point to start running JavaScript in your users’ browsers. CSP hashes are one of the cleanest ways to keep a small amount of inline JavaScript while still blocking everything else. This guide is the practical version: what hashes do, when to use them, how to generate them, and the exact headers to copy and paste. ...
Cross-site scripting is one of those vulnerabilities that never really goes away. We get better frameworks, safer templating, stricter defaults, and still XSS shows up in bug bounty reports every day. The reason is simple: if an attacker can get the browser to execute JavaScript you didn’t intend to run, they can often act as the user, steal data, or pivot deeper into your app. Content Security Policy, or CSP, is one of the few browser features that can meaningfully reduce the blast radius of XSS. It is not a silver bullet. It will not magically fix unsafe HTML rendering. But a good CSP can turn “one bad escaping bug equals account takeover” into “the payload just doesn’t run.” ...