Skip to content

navigate-to

navigate-to would have restricted the URLs a document may navigate to by any means - links, window.location, form submissions, redirects.

It was the one CSP directive that promised to constrain outbound navigation in general. The proposal ran into hard problems around redirects and privacy, and was dropped.

The parts of it that survive are narrower and real: form-action for submissions, frame-ancestors for embedding, and the sandbox navigation tokens.

Content-Security-Policy: navigate-to 'self';
  • Nothing. No browser implements it.

navigate-to has no fallback, and no fallback would matter: nothing implements it.

Content-Security-Policy: form-action 'self'
  • Cover the case that actually matters - where a form may post - with form-action, which is widely supported and has no fallback to default-src, so it must be written explicitly.
  • For link navigation there is no CSP answer. Validate redirect targets server-side; that was always the real control.
  • Never shipped. Chromium began an implementation and removed it; Firefox and Safari never started one.
  • Unknown directives are ignored, so its presence in a policy is harmless - and misleading to whoever reads the policy next.
  • No browser implements the directive, so no browser can report a violation of it.
  • HeaderHawk’s normalizer does accept navigate-to as a directive name, a holdover from when the directive looked like it would ship. The field exists; nothing will ever populate it.

Point your policy’s report-uri at your site’s HeaderHawk endpoint and the violations above arrive in the dashboard, grouped as described. The Quick Start sets that up in five minutes, and the integration guides cover the header syntax for each platform.