Script Injection

Script injection is an attack in which someone gets a website or browser to run JavaScript that its owner never wrote or approved. The injected code runs with the same access as the page's own scripts, so it can read page content, reach session data, submit forms, or redirect the visitor. Most script injection on the web is a form of cross-site scripting (XSS), although the term also covers code added to pages by browser extensions and user scripts.

The parts of an injection

Every script injection involves four elements. Understanding them makes it easier to see where a fix belongs.

• Injection point: any input the page accepts and later displays, such as a search box, a URL parameter, a comment field, or a profile name.
• Unsafe sink: the code path that writes that input into the page as markup or executable code, for example through innerHTML, document.write, or eval.
• Victim browser: the environment where the payload runs, with access to that site's cookies, local storage, and page structure.
• Payload: the script the attacker wants to execute, which can be as small as a single event handler.

Types of script injection

Reflected XSS. The payload travels in the request, usually inside a URL, and the server sends it back in the response without cleaning it. The attacker must get the victim to open a crafted link, which they often do through email, chat, or an advertisement.

Stored XSS. The server saves the payload, for example in a forum post, product review, or message, and serves it to every visitor who views that content. No tricked link is needed, so this type usually has the widest reach.

DOM-based XSS. The flaw lives in the page's client-side JavaScript. The script reads untrusted data from the URL fragment or another browser source and writes it into the page. The server never sees the payload, so server-side filters often miss it.

Browser-side injection. Extensions, user scripts, and some automation tools insert code into pages a user visits. Many of these tools are legitimate. Antidetect browsers such as Aurorium change how a page sees the browser, and automated collection tools often inject scripts to read rendered pages, as described in what web scraping is. The same mechanism is what malicious add-ons abuse, so the difference lies in consent and scope. To see which browser details a page's scripts can read, you can run the fingerprint check below.

Fingerprint Check

Run a full browser fingerprint check to see how uniquely your browser can be identified across the web.

Check Fingerprint

How a reflected attack unfolds

1. The attacker finds a page that prints a search term back to the visitor without encoding it.
2. They build a link whose parameter contains a script tag or an event handler.
3. They send the link to a target through email, a chat message, or a fake notice.
4. The victim clicks it. The server returns the page with the payload embedded in the HTML.
5. The browser runs the script as if the site had written it. Unless the session cookie is marked HttpOnly, the script can read it, or it can send requests that act as the user.

Each step depends on the one before it. Blocking any single step, such as the unencoded output in step 1 or the readable cookie in step 5, can stop the attack.

Risks and limits of the defenses

Script injection is hard to eliminate entirely. Developers often try to filter out the string <script>, but attackers have many other ways to run code, including image tags, SVG elements, and event attributes. Blocklists therefore give a false sense of safety. Automated scanners also struggle with DOM-based flaws because they require running the client code. For users, the main risk is installing browser add-ons or user scripts that have broad permission to read and change every page, since such tools can do what an attacker's script does.

Defenses for developers and users

Developers get the most protection from a layered approach:

• Encode output for its context. Text placed in HTML, attributes, JavaScript, or URLs each needs different encoding.
• Prefer safe DOM methods. Use textContent instead of innerHTML when the value is plain text.
• Sanitize rich content. If users must post HTML, run it through a vetted sanitizer library before display.
• Set a Content Security Policy (CSP). A CSP header tells the browser which script sources are allowed, which blocks many injected payloads even when a flaw exists.
• Mark cookies correctly. HttpOnly keeps scripts from reading session cookies, and SameSite limits cross-site requests.

Users can reduce exposure by keeping the browser updated, removing extensions they no longer use, and reviewing the permissions requested by any extension or user script before installing it.

Script injection compared with SQL injection

Script injection is often confused with SQL injection, because both insert untrusted input into a command the application later runs. The table shows where they differ.

Both are injection flaws, but they require different fixes. Parameterized queries do not stop XSS, and output encoding does not stop SQL injection.

What to check first

If you run a website, test every place where user input is shown back to visitors, and start with search, comments, and profile fields. If you use browser add-ons, remove any you do not need and check what they can read on each site. For background on the protocols that carry these requests and responses, see what a network protocol is.