Finland's largest bank OP (former Osuuspankki) has added tracking domains (all three owned by Adobe) in their website redesign:

uBlock Origin on uusi.op.fi

These domains are loaded when signed in:


Is this considered acceptable? What information can third-party domains gather on my bank account activity?

  • 8
    Are these domains embedded into the actual online banking or only in the website of the bank, i.e. on pages where you enter sensitive information or not on such pages? Commented Jul 29, 2017 at 19:48
  • 2
    @SteffenUllrich: demdex.net, omtrdc.net and occasionally 2o7.net are loaded when inspecting my account activity. The balance of my bank accounts is displayed on the front page.
    – user598527
    Commented Jul 29, 2017 at 19:56
  • 4
    Given the answer by Steffen, I hope you send(sent) your bank a warning message? And thanks for asking, I'll put this check on my to-do list.
    – user13695
    Commented Jul 30, 2017 at 10:28
  • 5
    This happened with another Finnish bank, S-Pankki, a couple years ago. Article in Finnish, sorry. tivi.fi/Kaikki_uutiset/2015-02-25/…
    – AKX
    Commented Jul 31, 2017 at 7:28
  • 2
    OP representative has responded, claims there's no threat (in Finnish): tivi.fi/Kaikki_uutiset/…
    – user598527
    Commented Jul 31, 2017 at 19:15

3 Answers 3


It looks like the main site is embedding script from Adobe Marketing Cloud directly into the page. While these scripts are loaded from the same server as the main site it looks like that these scripts communicate with external servers using XHR and also download new script from demdex.net and 2o7.net according to the logs of uBlock Origin.

Especially the loading and executing of new scripts from a third party outside the control of your bank is a huge security problem. Essentially these scripts can get full control over the web site, including reading what you enter, changing submitted or displayed content etc. These are essentially cross site scripting, only that they did not happen by accident but the developers of the banking site explicitly invited these third parties to do cross site scripting.

While such use of third party services might be acceptable on a site where no sensitive information is entered, it is absolutely not acceptable whenever sensitive information is transferred or when it unexpectedly changes to the content of a web site (like showing a different account balance) and might cause unwanted actions from the visitor.

  • 12
    @CC.: Yes, it's possible for Adobe to deliver scripts that submit arbitrary content of the current page (incl. account details) to whomever they want. Commented Jul 30, 2017 at 21:13
  • 5
    There are mechanisms that allow for integrity checking of third party scripts, ensuring they are the the ones expected by the developers of the primary site. (w3.org/TR/SRI) As such it is possible for this to be done safely.
    – Gary
    Commented Jul 31, 2017 at 0:34
  • 7
    @Harper. The code from the site that requests the third-party script has a checksum for the resulting script. The browser itself validates that the file returned has the checksum the bank's developers expected before it runs it.
    – Gary
    Commented Jul 31, 2017 at 4:18
  • 8
    Isn't whether or not to trust a third party vendor such as Adobe a business decision as well? Maybe the bank decided that their security and regulatory compliance is not compromised by including scripts from Adobe on the page? Commented Jul 31, 2017 at 9:05
  • 18
    @BaileyS: the problem is that the bank has no control over what the third party side does. Even if it trusts that the third party does not intend to do harm it has no control over the security of the third party and thus will be affected if the third party is hacked and serving different content. Thus the business decision is not only if it trusts Adobe's intend but also if it trusts Adobe to fully protect their infrastructure. And this might not be a good idea. Commented Jul 31, 2017 at 9:19

Banking sites are hardly monolithic. A bank usually relies on dozens or even hundreds of third party systems in their overall solution. You might have a banking host provided by one vendor, a credit card solution from two or three more vendors, a signon solution provided by yet another, payments by another. The work to put together these sites is enormous.

It is not at all uncommon for banking sites to involve third parties on the front end as well. This could range from third party libraries just to render a calendar control to systems that provide user behavior analytics and risk decisions. Many of these vendors offer script and content via content delivery networks (CDNs), meaning that the files might come from a third party domain.

Is this dangerous? It can be. If the third party resources are not verified via Subresource integrity, they could be modified by hackers (via Man-in-the-middle) or even the third party itself (e.g. malicious employee). So any online banking implementation will either host the content themselves (i.e. copy and paste the third party files onto their own web server) or in some cases deliver the content with a cryptographic hash, notated via the integrity attribute of the script node or link node that references the external file. In yet other cases, they will link to the CDN but provide fallback behavior to a local file (see this StackOverflow question) in case the SRI check fails.

Should I be worried of tracking domains on a banking website?

It is important to note that in the EU, the cost of fraudulent transactions is borne by the institution. Online banking security, therefore, has the primary mission of protecting the bank, not you.

Whatever architecture OP came up with, you can be certain that it passed several layers of risk assessment and review and the decision to use a CDN to serve some content was not made lightly. Chances are they have implemented it properly and are using some means of SRI. You can still worry, but the worry should be minimal.

  • 7
    Whilst it's true that the liability for fraud falls on the institution, it's still a bit of a nuisance to deal with until they accept it's their fault. Definitely worth avoiding, in my book. I wouldn't enable scripts on my bank's site, and certainly not third-party ones! Commented Aug 1, 2017 at 15:31
  • 6
    The cost of fraud is indeed borne by the bank (unless you were grossly negligent). But good luck convincing the bank that it wasn't you who made that properly authenticated transaction from your computer while you were logged in. Commented Aug 1, 2017 at 21:13
  • 1
    +1 for mentioning (SRI)subresource integrity. For those who don't know SRI verifies the hash of the third party code matches an expected value. As long as they use that, there really isn't anything malicious a third party could do without causing the SRI check to fail. However SRI is relatively new, and is not supported in IE or Edge, so they may not be using it. You must also be using Chrome of Firefox to receive this extra security protection. Commented Aug 3, 2017 at 6:37
  • 5
    Even if the 3rd party does not do malicious transactions, they might have access to the data.
    – JKAbrams
    Commented Aug 14, 2017 at 16:51

The chance is low but it could be a real threat. Recently (April 2017) it was discovered that tracking scripts (Gemius) on one of large Polish banks (mBank) was sending account balance together with other (standard) tracking data. The intended effect was probably capturing navigation (page titles/section) so leak itself might be accidental.

  • 3
    citation needed
    – A. Hersean
    Commented Aug 1, 2017 at 11:33
  • 4
    I don't know of any English source. the original discovery was published at: zaufanatrzeciastrona.pl/post/… It contains sample request to 3rd party server and bank response claiming it was accidental. Such requests no longer happen.
    – user158037
    Commented Aug 1, 2017 at 13:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .