I ran into an interesting situation recently while working with online banking integrations, and it’s a good reminder of how small implementation choices can lead to bigger security issues.
Both Banner Bank and Solarity Credit Union use the same third-party bill pay service. The difference is in how they integrate it:
-
Banner Bank opens the bill pay service in a new tab.
-
Solarity embeds it inside their website using an iframe.
At first glance, it doesn’t seem like a big deal — until you notice what happens when you have an active session with Banner and then access Solarity’s bill pay.
You can actually start to render Banner Bank’s session inside Solarity’s iframe before the system catches it and throws an error. It’s not a complete session takeover, but it’s one step closer to things like CSRF, session fixation, and other security problems you don’t want anywhere near a banking app.
Why This Matters
This is a textbook example of why embedding sensitive financial services inside iframes isn’t a great idea:
-
Sessions can leak or get mixed between banks
-
Modern browsers are increasingly strict about third-party cookies and cross-site content, meaning this type of integration is already fragile
-
It opens the door to unexpected, hard-to-debug security issues that shouldn’t exist in a production financial environment
How It Can Be Fixed
The clean, proper way to handle this is:
-
Use dedicated subdomains per client bank (e.g.,
solarity.billpaysite.comandbanner.billpaysite.com) to isolate sessions cleanly -
Or stop embedding entirely and open the bill pay service in a separate, isolated window or tab
Final Thoughts
If you’re building systems like this — or working with vendors that do — it’s worth taking the time to double-check how sessions and cross-origin content are handled. It’s one of those things that “works fine” until it quietly stops working, or worse, opens you up to a security issue you didn’t see coming.