# Does your browser code mix untrusted input with risky methods?

By Mark Kashef, founder of Lockpick. Published 2026-10-08, updated 2026-10-08.

This check flags scripts that both read input an attacker can control and call methods that insert or run content. It is a code review lead, not a proven bug.

This check flags a script that both reads input a visitor or another page controls, such as the address or a message from another window, and calls methods that insert or run content. It is a review lead.

## What does this check look at?

It looks at whether a sampled script both reads input a visitor or another page controls and calls methods that insert or run content. When the two meet without the right encoding, the result is cross-site scripting. MDN describes it as tricking the target site into executing malicious code within its own context.

Pulse and Deep scans both run it.

## What does a result mean?

| What the report shows | What it means | What to do |
| --- | --- | --- |
| Info finding | A sampled script contains both an input and a risky method. | Trace whether the input reaches the method without encoding. |

It is a lead for code review, and no data flow or cross-site scripting is shown. The two may be unrelated or already handled safely. A clean result means nothing was found in what the scan read. It does not prove the problem is absent from parts the scan never sees.

## How serious is a finding?

This is information only. It claims no weakness, so it carries no verdict, and you decide whether anything should change. Confidence starts at medium, because it rests on a pattern in your content. The report lists what to fix by how directly someone could use it, not by the severity label.

## Which standards does it relate to?

| Standard | Reference |
| --- | --- |
| OWASP Top Ten | `A05:2025` Injection |
| CWE | `CWE-79` |
| ASVS | `v5.0.0-1.2.1` |

Each one is a related control, not a verification. A scan sees what anyone online can see, so it never proves a whole requirement is met.

## Fix it with your AI

This needs a careful read of the code, which is a good job for an AI with your repository open.

:::fix-prompt any
Review my front-end code for DOM cross-site scripting. Find every place that reads location (hash, search, href), document.referrer or postMessage data, and trace whether that value can reach innerHTML, outerHTML, insertAdjacentHTML, document.write, eval, new Function, setTimeout with a string, or dangerouslySetInnerHTML. For each path, tell me if it is safe and why, and fix the unsafe ones with textContent, proper encoding or a sanitizer. Check postMessage handlers verify event.origin.
:::

## How to check

Say Atlas, our example app at `atlas.example`, reads a search term from the address and shows it with innerHTML. The check flags the script, and the fix switches to textContent.

Run a Pulse scan from your Lockpick account to see it for your site. [Pulse or Deep](/docs/get-started/pulse-or-deep) explains what each scan reads, and the [full list of checks](/checks) shows the rest.

## Questions people ask

### Does this finding mean my site has cross-site scripting?

No. It means one script contains both halves of the pattern. Whether data flows from one to the other needs a code review.

### Will a Content Security Policy help here?

Yes, as a second barrier. A strict policy can stop injected script from running even if a bug slips through.

## Sources

- [Cross-site scripting (XSS)](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/XSS), MDN Web Docs, read on 2026-10-07
- [How we rate findings](https://www.lockpick.app/docs/security/how-we-rate-findings), Lockpick docs, read on 2026-10-07