Third-party JavaScript running in your page can access everything on it. Here's the security question that almost never comes up in bank and credit union vendor evaluations — but should.
If you've been through a vendor evaluation for financial tools recently, you may have heard concerns about how the tool is delivered to your website. Does the integration method affect SEO? Can analytics see inside the tool? Does the vendor control your brand?
These are reasonable questions, and we addressed them in the previous posts in this series. But there's another question that almost never comes up in these conversations — one that your information security team would want asked if they were in the room. And it points in exactly the opposite direction from the concerns you've probably heard.
The question is this: what can a vendor's code actually access on your website?
When a vendor delivers a tool as a JavaScript file that runs directly inside your website, that code inherits the full privileges of your page. It can read form fields. It can access session information. It can interact with anything visible in the browser at that moment. In most cases, the vendor has no malicious intent — but the exposure exists regardless of intent.
The relevant risk isn't what the vendor would do. It's what becomes possible if their systems were ever compromised. A vendor whose JavaScript is embedded directly in your page becomes, in a security sense, part of your attack surface. If that vendor's content delivery were ever tampered with, malicious code could execute inside your customers' browser sessions — with access to everything your page can see.
This is not a theoretical concern. It's a documented attack pattern, and it's why the web security community has been explicit about it.
Vendor JavaScript runs with full access to your page's context — form fields, session data, cookies. A compromise of the vendor's systems could affect your customers' sessions. Your team carries the risk.
The tool operates in an isolated container. It cannot access your page's data, cookies, or session information. The security boundary is structural — it doesn't depend on vendor behavior or ongoing trust.
The security boundary isn't a limitation. It's the entire point.
Consider how Stripe processes a credit card number on a merchant's website. Or how PayPal handles payment credentials. Or how virtually every major payment technology provider in the world delivers its card input fields. None of them run directly in the merchant's page. All of them deliver their most sensitive functionality inside an isolated container — precisely because the security model requires it.
The same logic applies to financial calculators and estimators on bank websites. These tools interact with customers during moments of financial consideration — they're exploring a mortgage, estimating a payment, thinking about their savings. The delivery architecture should reflect the sensitivity of that moment.
Sandboxed delivery is not a legacy approach or a technical workaround. For the payment industry, it became the standard because the alternative carries a structural risk that responsible institutions don't accept. Financial tool delivery should be evaluated through the same lens.
You may encounter a competitor or consultant who dismisses sandboxed delivery with a variation of this claim: "iFrames are old technology." It's worth addressing plainly, because it gets the argument exactly backwards.
Yes, the iFrame — the container that creates an isolated browser context — has been part of web standards for decades. So has HTTPS. So has the canonical link element. The age of a technology is not an argument against it; it's often evidence that it has been tested, refined, and trusted at scale.
More importantly: every major payment provider on the internet uses sandboxed delivery for its most security-sensitive functionality. When you enter a credit card number on a merchant's website using Stripe, that input field isn't running in the merchant's page — it's in an isolated container. Same with PayPal. Same with virtually every payment gateway that takes security seriously. They don't do this because they haven't found something better. They do it because the isolation is the security model. The container is what prevents the merchant's page — or anything injected into it — from touching your card number.
The same principle applies to financial calculators on bank and credit union websites. When a competitor calls sandboxed delivery "outdated," ask them to explain how their JavaScript widget handles a supply chain compromise — a scenario where their delivery infrastructure is tampered with and their code begins executing in your customers' browser sessions with full access to your page. That's not a hypothetical. It's a documented attack class. And it's exactly what sandboxed delivery is designed to prevent.
The architecture isn't a legacy constraint. It's the reason the security boundary exists at all.
Most marketing and digital product teams aren't in the habit of thinking about vendor evaluation through a security architecture lens — and that's entirely understandable. It's not your primary domain, and vendors rarely volunteer this framing when the alternative might be disadvantageous to them.
But if your institution has an information security team involved in technology evaluations — and most institutions of any size do — this is a conversation worth surfacing. The question "what can this vendor's code access on our site?" is one they'll want answered. The architecture of delivery is one of the clearest ways to answer it.
We've been having this conversation with banks and credit unions for nearly two decades. We raise it because we think it's the right question — not because we always benefit from it being asked. Institutions that understand the full picture make better decisions. And we'd rather work with institutions that have made an informed choice than ones who didn't know they had one.
Get a guided tour of the Solution Suite tailored to your institution's lines of business — typically 30 minutes, with the team that would run your implementation.
.svg)
.svg)