Web-Security

XSS in URL parameters URL parameters are one of the most common places where XSS starts. They feel harmless because they arrive as plain text: https://example.com/search?q=shoes Then somebody reads q, drops it into the page, and now you have script execution. The vulnerable pattern is usually boring: const params = new URLSearchParams(window.location.search); const q = params.get('q'); document.getElementById('search-label').innerHTML = `Results for: ${q}`; If q is: <img src=x onerror=alert(1)> you just handed the browser executable HTML. ...

Jekyll is a static site generator, which makes people assume it’s automatically safe from XSS. That’s a bad assumption. Static output can still ship dangerous HTML and JavaScript to every visitor. If untrusted content gets into your templates, markdown, front matter, data files, or generated JSON, you can absolutely create stored XSS in a Jekyll site. The fact that the site is “just files” doesn’t help once the browser starts parsing them. ...

Excel web add-ins are just web apps wearing an Office badge. That sounds obvious, but teams forget it all the time. I’ve seen this play out the same way more than once: a team builds a task pane add-in, treats workbook data like “internal content,” renders it into the DOM, and accidentally creates a clean XSS path inside Excel. The UI looks harmless. The payload comes from a spreadsheet cell, a custom function result, or a document setting. Then somebody pastes attacker-controlled content into a workbook, shares it, and the add-in executes script in the task pane. ...

Cognito Forms is convenient. That’s why teams use it. You get hosted forms, calculations, workflows, payments, and embeds without building the whole stack yourself. The security catch is the same one you get with any third-party form platform: user-controlled content eventually gets displayed somewhere. If that content is rendered unsafely in a browser, you have an XSS problem. For developers, the real question usually isn’t “Does Cognito Forms have XSS?” It’s “Where can XSS happen in the way we use Cognito Forms, and which defenses are actually worth the complexity?” ...

Server-side rendering feels safer than shipping a giant client-side app. A lot of HTML is generated on the server, templates usually escape output by default, and there is less obvious DOM manipulation in the browser. That safety is real, but people overestimate it. I’ve seen teams say “we use SSR, so XSS isn’t really a concern.” Then you look at the code and find raw HTML helpers, unquoted attributes, JSON blobs jammed into <script> tags, and a CSP that exists only in a slide deck. SSR reduces some attack surface. It does not remove the core problem: if untrusted data lands in the wrong output context without the right encoding, you still have XSS. ...

Content Security Policy nonces are one of the cleanest ways to shut down a huge class of XSS bugs without rewriting every frontend template you own. If you’ve ever inherited a server-rendered app with inline scripts sprinkled everywhere, nonces are usually the fastest path to meaningful protection. They let you keep specific inline <script> and <style> blocks while blocking attacker-injected ones. The short version: The server generates a fresh random nonce for every HTTP response That nonce goes into the CSP header The same nonce is added to trusted inline <script> or <style> tags The browser executes only the tags with the matching nonce If an attacker injects <script>alert(1)</script>, it won’t have the right nonce, so the browser refuses to run it. ...

Make is great at moving data between systems. That convenience is exactly why XSS can sneak in so easily. I’ve seen teams assume XSS is only a frontend bug. Then they wire Make into forms, CRMs, CMS tools, Slack, email builders, internal dashboards, and webhook handlers. Suddenly untrusted input is flowing through ten services, getting reformatted three times, and landing in HTML somewhere nobody reviewed carefully. That’s the real problem with XSS in Make automations: Make usually isn’t the final vulnerable layer, but it can absolutely become the delivery mechanism. ...

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

Cross-site scripting gets most of the attention, but SVG-based attacks keep showing up in bug bounty reports, file upload flaws, and chat apps that “support rich images.” If you build web apps, you should treat SVG as part image, part document, part script container, and part footgun. The tricky part is that XSS and SVG attacks are not competing categories. SVG attacks often become XSS. That overlap is exactly why teams underestimate them. ...

If you embed a chat widget, you’re adding a third-party UI surface that touches user-controlled data: names, emails, pre-chat forms, custom variables, URLs, campaign tags, support messages, and sometimes your own CRM content. That makes LiveChat-style widgets a classic XSS boundary. The main rule is simple: treat everything that enters or leaves the widget as untrusted. This guide focuses on the places developers usually get burned when integrating a LiveChat widget and shows safer patterns you can paste into real code. ...