Set a Custom Content Security Policy (CSP)

Set a custom Content Security Policy (CSP) with PHP to allow a specific Oncord page to be embedded on another website.

This tutorial uses an embeddable form as an example. Add the header to the Oncord page that contains the form.

Oncord's Default Policy

Oncord normally sends the following CSP for HTTPS requests:

Content-Security-Policy: default-src 'unsafe-inline' 'unsafe-eval' data: blob: https: wss:; frame-ancestors 'self'

The default-src directive sets the default resource-loading policy. The frame-ancestors 'self' directive allows the page to be framed by pages on the same origin (scheme, hostname and port), and blocks framing by other origins.

To permit an external website to embed your form, replace the header for that page and add the external origin to frame-ancestors.

Add the PHP Header

1. Go to Website > Pages and edit the page you want to embed, for example /embed-form/.
2. Click SRC / Source, then select the PHP tab.
3. Add the following code at the start of the page's PHP script. Replace https://parentdomain.com with the origin of the website that will contain the iframe.

<?php header("Content-Security-Policy: default-src 'unsafe-inline' 'unsafe-eval' data: blob: https: wss:; frame-ancestors 'self' https://parentdomain.com", true);

If the PHP tab already contains code, add the header() line inside its existing PHP block. It must run before any output is sent, including output from echo or print. Place it directly in the script so it runs when the page loads; it does not belong inside a form-submission handler. See Working With PHP for the editor basics.

Save the page, then test it in the external website's iframe.

The true argument replaces an earlier CSP header set by PHP. It replaces the whole policy, so this example retains Oncord's current default-src value and changes only the allowed frame ancestors. If your page already has a custom policy, preserve its other directives too. PHP's header() reference explains replacement and output timing.

Apply the Policy to a Page or Website Design

For a page-specific change, add the header in that page's PHP tab. For a global change across pages using a website design, go to Website > Designs, edit the design, click SRC / Source and select the PHP tab. Add the header at the start of the design's PHP script, before any output. If your website uses multiple designs, update each applicable design. Check for page-level CSP overrides and verify the final response headers.

A URL beginning with /embed- does not automatically change the policy.

Choose the Allowed Origins

Separate origins with spaces. For example, https://parentdomain.com https://preview.parentdomain.com allows both sites. Keep 'self' if the page should also work inside an iframe on its own origin.

For security, you must specify the exact trusted domains that are allowed to embed your pages, including the scheme (for example, https://parentdomain.com). Do not use wildcards such as * or https://*.parentdomain.com.

You are responsible for the security of your custom CSP, including checking that every allowed domain is trusted and that the policy is appropriate for every affected page. Allowing another site to frame your pages can expose visitors to clickjacking. Take particular care with design-level changes because they affect multiple pages.

Example: Published Sites and Editor Previews

Site builders can use different domains for their published pages, previews and editors. This example allows only the exact published, preview and editor origins listed:

<?php header("Content-Security-Policy: default-src 'unsafe-inline' 'unsafe-eval' data: blob: https: wss:; frame-ancestors 'self' https://parentdomain.com https://preview.parentdomain.com https://editor.parentdomain.com", true);

Replace these placeholders with your actual trusted origins. List each required subdomain explicitly; allowing https://parentdomain.com does not automatically allow https://preview.parentdomain.com.

A working published page does not prove the editor preview will work. With nested iframes, every ancestor origin must be allowed, including the outer editor. Check the browser console and frame tree for the actual origins. For example, if an ancestor is https://editor.parentdomain.com, include that exact origin in the list. The example above is not a guarantee that every editor or preview surface is covered. See the CSP frame-ancestors specification.

Verify the Response

1. Open browser developer tools, select Network, and reload the page containing the iframe.
2. Select the Oncord document request for your embedded page. Under Response Headers, check that Content-Security-Policy contains the intended allowed origins.
3. Check the console for framing errors. Test the published page and editor preview separately, then submit a test form and confirm the expected Oncord submission and notifications.

If another enforced CSP still contains frame-ancestors 'self', it can continue blocking the embed. Multiple policies are enforced together; adding a more permissive header with false will not relax the original. A proxy or CDN may also add a policy after PHP runs. Check the final response rather than just the PHP source.

frame-ancestors must be delivered in an HTTP response header; putting it in an HTML <meta> tag will not work. The external website's own frame-src policy or iframe sandbox can also block loading or form behaviour. A CSP change on the Oncord page cannot override those restrictions.

To restore the normal policy, remove the custom header line from the page or design where you added it, save your changes and verify the response headers again.