ADsafe
Menu

ADsafeContent Security Policy and third-party scripts

Illustrative photo for the widget boundaries article; AI-generated.
Explore the historical boundary diagramDiagram of host authority, mediated DOM operations and restricted guest code; historical model, not a security guarantee.

ADsafe Reference

Content Security Policy and third-party scripts

Content Security Policy controls what a document may load and run, which makes it useful around third-party scripts. It does not give an allowed script less authority than the host page's own code, so it answers a different question from a widget-isolation design such as ADsafe.

What a policy is

MDN describes Content Security Policy (CSP) as instructions from a site that tell the browser to restrict what the site's code is allowed to do. It is normally delivered in the Content-Security-Policy response header, as directives separated by semicolons. Its main use is to control which resources, especially JavaScript, a document may load, as a defense against cross-site scripting.

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://widgets.example;
  connect-src 'self';
  frame-src https://widgets.example;
  object-src 'none'

What it restricts

  • Script sources. script-src limits where scripts load from, and it also governs inline event handlers. If a policy has default-src or script-src, MDN says inline script is blocked unless a nonce, a hash or 'unsafe-inline' permits it.
  • String-to-code APIs. With the same directives present, eval(), the Function() constructor and string arguments to setTimeout() are blocked unless 'unsafe-eval' is present.
  • Network calls from script. connect-src covers fetch(), XMLHttpRequest, WebSocket, EventSource and navigator.sendBeacon(), among others.
  • Frames. frame-src limits what the page may embed, which differs from frame-ancestors, which limits who may embed the page.
  • Sandboxing. The sandbox directive applies iframe-like restrictions to the document the policy is attached to. MDN notes it is not supported in a <meta> element.

What it does not restrict

The policy is delivered by the host page, so it protects the host from what the host chooses to load. It is not a statement the guest makes about itself. A policy decides whether a script may load or run. Once a script is allowed, it runs with the authority of the page. MDN's description of cross-site scripting makes the point: injected code can access or modify the content of loaded pages, read local storage, and make requests with the user's credentials, in other words anything the site's own code could do. The same holds for a third-party script that the policy deliberately allows.

  • CSP does not hide document, window or the cookies and storage visible to the script from an allowed script.
  • It does not separate one allowed script from another on the same page. A widget and the host's code share globals unless something else separates them.
  • A broad allowlist lets in everything those hosts serve. MDN's strict CSP guidance notes that allowlist policies are hard to get right and recommends nonce- or hash-based policies where possible.
  • A policy limits destinations only for the request types its directives cover. Check each directive you rely on against the MDN reference.

How this differs from the ADsafe approach

ADsafe restricted what code could be written, then gave that code a mediated DOM. A policy restricts where code comes from and which dangerous APIs are reachable. In ADsafe's design the host approved script URLs for libraries, and widgets could not use eval. CSP can enforce the second point at the document level for every script, including ones nobody verified. It cannot enforce the first point, because it has no notion of a restricted DOM.

This suggests a layered view. Use isolation, such as a sandboxed frame, to limit what the widget can reach. Use CSP to limit what the host page loads and where an embedded document may connect. Use review of what each embed receives to catch the rest.

A practical checklist

  1. List each third-party script, the origin it loads from, and the origins it contacts.
  2. Prefer nonces or hashes for scripts you control. Avoid 'unsafe-inline' and 'unsafe-eval', which MDN advises against.
  3. Set object-src 'none' and a tight frame-src.
  4. Test with the Content-Security-Policy-Report-Only header first, so violations are visible before they are enforced.
  5. Treat any script that must run in your page as having your page's authority, and decide whether it should run in a frame instead.
  6. Re-check the policy whenever a vendor adds a new host, because an allowlist grows silently when a script loads further scripts.

ADsafe is a historic project. This site is an independent reference, is not the official ADsafe site, and is not endorsed by the author of ADsafe. It does not offer ADsafe as a currently reviewed security boundary. For the reasoning behind restricting eval, see why eval and global access are restricted.

Primary sources

Related guides

Independent educational explanation. Read alongside the cited sources; this page does not certify the historical runtime as a current security boundary.