Cross-Site Scripting

Cybersecurity 21 Sep 2026 5 min read

Trusted Types Put DOM Injection Sinks Behind Policies

Trusted Types Put DOM Injection Sinks Behind Policies DOM-based cross-site scripting often appears at the last step of a data flow. A value moves through application code as an ordinary string, then reaches an API that interprets it as HTML, script, or a script URL. The dangerous boundary is not the string alone; it is the moment that string enters an injection sink. Trusted Types changes that boundary. In supporting browsers, an application can require covered sinks to receive objects such as TrustedHTML, TrustedScript, or TrustedScriptURL instead of raw strings. Those objects are created through policies defined by the application.

Cybersecurity Web Security

Cybersecurity 12 Sep 2026 8 min read

Use CSP Nonces to Restrict Executable Scripts

Cross-site scripting becomes dangerous when attacker-controlled text reaches a browser in a form that the browser can execute. Context-aware output encoding and safe DOM APIs remain primary defenses because they stop data from becoming executable markup. A Content Security Policy can add another boundary: even if an injection flaw creates a script element, the browser can refuse to execute it unless the page explicitly grants that script permission. A nonce-based policy is a practical way to express that permission for server-rendered pages. The server creates an unpredictable value for one HTTP response, places it in the Content-Security-Policy header, and attaches the same value to script elements that the application intends to execute. A script inserted through an injection flaw does not possess the value and is blocked.

Cybersecurity Web Security

Cybersecurity 08 Sep 2026 12 min read

Use Content Security Policy as XSS Defense in Depth

A web application can carefully encode output and still acquire an injection bug later through a new template, a third-party component, or unsafe client-side code. If attacker-controlled text reaches a place where the browser interprets it as JavaScript, the result can be cross-site scripting (XSS): code runs in the security context of the application and can act with whatever authority the page already has. The primary fix is to stop untrusted data from becoming executable code. Content Security Policy (CSP) adds a second boundary. The server sends a policy that tells the browser which scripts are allowed to execute. A well-designed policy can therefore reduce the impact of some XSS flaws even when the application accidentally places attacker-controlled markup into a page.

Cybersecurity Web Security