Preventing XSS in Basin Apps

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

April 7, 2026 · 7 min · headertest.com

XSS Risks in Airtable Embeds and How to Stop Them

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

April 6, 2026 · 6 min · headertest.com

Using Hashes to Stop Inline Script XSS

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

April 5, 2026 · 6 min · headertest.com

How Content Security Policy stops XSS

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

April 4, 2026 · 8 min · headertest.com