Safety & Security
The scripts you did not choose: third party code on the pages you visit
An ordinary page loads code from a dozen companies. When one of those is compromised, every site including it is affected at once.
Updated 6 min readqikfox
The short answer
Most web pages load executable code from several other companies for analytics, advertising, support widgets, fonts and payment forms. That code runs with the same access as the site's own, so a single compromised supplier can affect thousands of sites simultaneously, which is why this class of incident keeps recurring.
Key points
- Third party scripts run with the page's full privileges, not in a sandbox.
- One supplier compromise reaches every site that includes it.
- Payment and login pages are the highest value places for injected code.
- Site operators can reduce this substantially; visitors can only reduce exposure.
Why this is structurally fragile
When a site includes a script from another domain, it is delegating execution to whoever controls that domain, now and in the future. The browser has no way to know the difference between the intended analytics code and something else served from the same place tomorrow.
That delegation is usually made once, by whoever set up the tag, and then forgotten across years of ownership changes at the supplier.
What injected code can do
Read anything on the page, including what is being typed into a form before it is submitted. Modify what is displayed, including account numbers and payment details. Send all of it somewhere else.
This is why checkout and sign-in pages are the targets. The code does not need to break encryption or defeat the server; it is already inside the page where the data is entered.
- Capture form fields as they are typed.
- Alter displayed payment destinations.
- Add an extra field that looks native to the page.
- Exfiltrate quietly to a domain that resembles a normal analytics endpoint.
What site operators can actually do
Keep an inventory of every third party script and why it is there, remove what is unjustified, pin what remains with integrity hashes where possible, and constrain what the page may load and where it may send data.
Keep payment and authentication pages as close to script free as the platform allows. The cheapest control is a shorter list.
What visitors can do
You cannot audit someone else's page, so the useful moves are to reduce how much of it runs and to be deliberate about where financial details are entered. Content blocking reduces the surface, and payment methods that do not expose a reusable card number reduce the value of what can be captured.
The habit that pays off most is unrelated to blocking: check statements. Injected skimmers are usually discovered by customers noticing charges, not by the sites they came from.
Questions and answers
Related qikfox pages
What tracking collects
The mechanisms behind these scripts.
Security at qikfox
How we approach protection.
Technology
How the products are built.
Security Center
Advisories and notices.
Back to The Perspective · Written and reviewed by the qikfox editorial team. Published .
Put the advice into practice
qikfox Safe Browser applies most of what this article describes by default, and works alongside qikfox Search, Antivirus and VPN.