Office SDK
See the workflow
All storiesSecurity
SecurityGuide4 min read

Content Security Policy for embedded editors: frames, connections, and origins

Use a narrow, tested content security policy for the host page and understand which controls belong to the embedded origin.

Office SDK EditorialOffice SDK Editorial
022
Content Security Policy for embedded editors: frames, connections, and origins: Host policy, Frame boundary, Resource origins, Policy reports.
Security / Office SDK

Build the host page's Content Security Policy from the resources that the host loads, and inspect the embedded editor's policy separately. A host's frame allowlist does not configure every script or connection inside the frame. Identify the context making the blocked request before changing a directive.

Determine which page owns the blocked request

The host page's policy governs resources and frames loaded by that page. The embedded document's own origin and headers govern its internal context according to browser rules. Allowing an editor in frame sources does not automatically configure every resource inside that editor. Likewise, the editor service must permit embedding by the intended host through its supported policy. Map these directions explicitly. This helps distinguish a frame blocked by the host from an editor response that refuses its ancestor, two failures that can look similar to users.

Observed failurePolicy boundary to inspect
Host cannot create the frameThe host's frame-loading policy
Editor refuses the host as an ancestorThe editor response's embedding policy
Connection fails inside the editorThe requesting frame's connection policy
Host integration script is blockedThe host's script policy and loading mechanism

Read the browser violation message for the effective directive, blocked resource, and frame context. Do not assume a hostname appearing in the console belongs in every directive. A conversion download, a websocket connection, and an embedded frame can need different policy treatment even when they share an origin.

Start with documented required origins and observe complete workflows in a controlled environment. Report-only collection can help discover omissions, but review extension noise and redact sensitive URL details before storing reports. After enforcement, repeat export, reconnect, and failure recovery: a policy that permits the initial shell may still block a resource requested only after the user edits. Keep the exact reviewed header with the deployment configuration so policy drift is diagnosable.

Host policy, editor policy, and browser evidence are compared by responsibility.
Figure 1. An ancestor-policy failure needs a different fix from a blocked connection inside the frame.

Inventory the complete resource path

Capture a representative successful workflow in a controlled environment and identify scripts, frame destinations, network connections, workers, fonts, images, and media. Include save, reconnect, export, and error recovery paths, not just initial loading. Compare the inventory with the vendor's deployment documentation. Use exact trusted origins where practical and understand any required schemes such as data or blob before allowing them. Avoid copying a policy from an unrelated deployment whose hostnames, authentication routes, and resource packaging may differ from the system being integrated.

Move from observed reports to enforcement

A report only policy can reveal violations before enforcement, where the browser and deployment support that approach. Review reports for real application needs, extension noise, and sensitive URL data before broadening the policy. Configure collection and retention deliberately. Then enforce the reviewed policy in a test environment and validate normal and failure flows. A violation should lead to a specific explanation and minimal change, not an automatic wildcard. Keep policy changes versioned alongside application releases so a newly blocked resource can be traced to a concrete deployment decision.

Keep the policy reviewable

  • List trusted origins by resource purpose and ownership.
  • Verify both the host's embedding permission and the editor's ancestor policy.
  • Test connection, worker, font, export, and reconnect paths.
  • Review violation reports before adding new sources.
  • Keep a tested rollback policy for deployment mistakes.

Example: the frame opens but saving fails

Use a test editor deployment whose initial assets load while a required connection destination is intentionally absent from the relevant policy. Open a synthetic document and attempt the operation that uses that connection. Inspect browser security messages and the policy of the context making the request. Restore only the documented destination and retest. This example demonstrates why successful initial rendering does not prove complete policy coverage, and why changing the host's frame allowlist may not fix a connection initiated inside the embedded page.

A later operation can reveal a policy omission that initial loading did not exercise.
Figure 2. Avoid expanding every source list when one context-specific dependency is missing.

Further reading

Back to all stories

Keep reading.

All stories