When you have all these various javascript files included on a page for various services like website analytics, click tracking etc., doesn't this create a huge security risk because using javascript they can hijack the persons credit card that is entered on the form?

How is this even considered to be safe currently?

Meaning, your server is security, your payment provider is secure, you have SSL, but if someone was to hack into any of these services people use (I see over 10+ services many sites use to track clicks, ad related, etc) then they can prise your payment form.

When you have all these various javascript files included on a page for various services like website analytics, click tracking etc., doesn't this create a huge security risk because using javascript they can hijack the persons credit card that is entered on the form?

How is this even considered to be safe currently?

Meaning, your server is security, your payment provider is secure, you have SSL, but if someone was to hack into any of these services people use (I see over 10+ services many sites use to track clicks, ad related, etc) then they can prise your payment form.

• javascript
• security
• stripe-payments
• pci-pliance

Share Improve this question Follow edited Nov 23, 2015 at 19:30 cool breeze asked Nov 23, 2015 at 18:49 cool breezecool breeze 4,81177 gold badges4545 silver badges7373 bronze badges

Add a ment  | 

2 Answers 2

Sorted by: Reset to default 9

Yes this is a security risk, known as a third party script include.

By including a script on your page hosted by a 3rd party, you are trusting that the external domain is not malicious nor promised. By using a <script src="//example."> tag, the third party domain has full control of the DOM on your site. They can inject whatever JavaScript they wish.

You are right to be concerned. PageFair was recently promised bringing down every site that it offered its analytics service to with it. You should verify all third party domains that you are referencing for script, and ensure you trust them. For example you are probably OK with the big guys such as Google and Facebook, however any others you should consider either dropping them or reviewing the script code and then hosting locally on your domain instead.

You can mitigate this with subresource integrity:

<script src="https://example./example-framework.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
        crossorigin="anonymous"></script>

This will ask the browser to check that the loaded script has the specified cryptographic hash. Any changes to the script, even as much as a single character, would produce a pletely different hash enabling any changes to be detected and the script would be rejected from loading and running. As of August 2018, all major browsers support it except for IE and iOS Safari.

EDIT: As has been pointed out to me in the ments, you cannot solve all of your JavaScript security problems by downloading all of the resources over HTTPS, as I asserted in a previous version of this answer. Instead, that simply reduces the problem to how much your end user can safely trust the provider of the JavaScript itself - and if the service gets promised or is an actively malicious organization, they can't.

There are two primary ways that hosts can solve this problem and make their JavaScript downloads more reliable for their users:

1. Where it doesn't make sense, don't include the JavaScript ponent at all. One thing you will notice on Amazon., for instance, is that while the normal shopping pages have header bars and are full of extra information and advertising and all that, the actual checkout page, where you enter your payment information, is almost blank - most of the styling and scripting is not included, and there are certainly no ads on the page.
2. If you need the ponent, but can host the script yourself, do so. That way, unless you yourself are promised, you can be confident that any script being downloaded by the user is not, because you are providing it. For offline scripts that don't actively municate with other services, this is often needed anyway for patibility reasons, and many online scripts can also be included here without too much loss in functionality.