Content Security Policy basics

What it means

A policy directive names what is being restricted; its source expressions or other permissions determine which attempts pass that check. Here, script-src governs the modeled scripts, and 'self' means the document’s own origin. The question is not simply whether a script exists, but whether that particular script fits the applicable restriction.

This page compares same-origin external scripts, third-party external scripts, and two inline cases. It concerns restrictions on resource loads and execution, not CORS rules for access to cross-origin responses.

Try it

Simulation: start with Policy = self and Script kind = third-party. Change only Script kind to same-origin, then select Compare with baseline to place the documented baseline and current outcomes together. Inspect why the result changed. These controls evaluate a local example; they do not test or modify a website.

The initial result is “Blocked by the modeled script check.” The evaluated explanation is “script-src 'self' is tested against third-party.” The third-party external source does not match the same-origin restriction. This is one content-security check, not a guarantee against XSS or approval to deploy the example policy.

Keep Policy = self. Change only Script kind from third-party to same-origin; do not change the policy while making this comparison.

Reset restores Policy = self and Script kind = third-party, removes input errors, and clears the baseline comparison. Changing either selection also clears an existing comparison. There is no running clock or stored event history to reset. Reset preserves your independent choices to open or close FAQ answers and About this model.

How it works

The useful distinction is between an external script’s source and an inline script’s authorization. For an external script, this scene compares the source classification with the selected policy. Under script-src 'self', a same-origin external source matches and a third-party source does not. That match or mismatch is the intermediate condition that produces the permitted or blocked result.

Inline script does not gain permission merely because a network source would match. In particular, script-src * does not by itself authorize inline execution. This is why changing a source list and authorizing inline code are not interchangeable operations.

The nonce-only selection represents script-src 'nonce-demo'. In this scene it permits the inline nonce-matching case because the script’s nonce matches the value authorized by the policy; it blocks the other listed cases. The fixed token makes that relationship inspectable, but it is not a nonce design to copy. A production nonce must be unpredictable and generated for each response. The scene tests classifications, not the generation or secure handling of real nonce values.

Worked example

This is a synthetic baseline, not a captured browser observation.

The selected policy represents script-src 'self'. The attempted script is external and classified as third-party, so its source does not match 'self'. That failed match leads to “Blocked by the modeled script check.” Nothing in this result establishes whether a real page delivers this policy, needs that script, or has other security controls.

What changes when the condition changes

Change only Script kind from third-party to same-origin, leaving Policy = self. The result becomes “Permitted by the modeled script check.” The evaluated explanation is “script-src 'self' is tested against same-origin.”

The policy did not become less restrictive. The attempted external script now matches the origin allowed by that same policy. This isolates the cause of the changed result: a different source relationship, not a different security setting. Permission here still describes only this one check.

In practice

Start with read-only evidence from a site you own or are authorized to inspect: the policy actually delivered for a representative document, the external scripts it needs, and any inline script behavior. Keep the scope to that document and those attempted actions. You are looking for a relationship between a restriction and a required behavior, not merely whether the policy looks valid.

For a comparable external-script check under script-src 'self', the expected distinction is between a same-origin source and a third-party source. If an observation does not fit that simplified explanation, stop applying this model and collect the complete policy and script context. The scene cannot resolve a configuration that uses features it omits.

Report-only can help collect observations without enforcing that policy’s restrictions, but it does not itself block the reported behavior. Do not broaden a policy merely to silence every report. Keep output encoding and other injection defenses, and never copy the fixed demonstration nonce into production. This page provides no deployment procedure: production changes need a separate authorized test plan, verification of required behavior, and a way to restore the prior configuration.

Limits and unknowns

The scene covers only its listed script classifications and three simplified script-src policies. It does not evaluate strict-dynamic, hashes, eval, multiple policies, or a complete policy’s interactions. A real page’s behavior and resistance to cross-site scripting remain unknown from this example.

If the current input is invalid, no calculated outcome applies until you correct it or use Reset; an earlier result must not be treated as the answer for invalid input. Valid supported selections yield a local permitted/blocked decision. They do not automatically detect when a real configuration falls outside the model.

The fixed demo nonce is not safe for production. No visitor-supplied script is executed. Without JavaScript, the initial example and explanatory text remain readable, but the controls do not operate.

What to carry forward

Ask two questions when interpreting a script restriction: which policy applies, and what kind of script is attempting to run? A permitted external source does not establish permission for inline execution, and passing one CSP check does not establish that the application is secure. Your next useful observation is the actual policy together with the script behavior it must govern—not a broader allowlist chosen only to make a warning disappear.