Can You Bypass X-Frame-Options?
Not from ordinary parent-page code. The useful question is who controls the framed page, because that determines the legitimate fix.
A framing policy belongs to the framed site
If a remote page sends X-Frame-Options: DENY or SAMEORIGIN, the browser evaluates that instruction before displaying the page in your iframe. CSS, iframe attributes and JavaScript on the parent page do not grant permission that the destination denied.
The same principle applies to Content Security Policy frame-ancestors, which is the modern and more flexible way for a site to define which parent origins may frame it.
Scroll horizontally to read every column.
| Situation | Correct path | What not to do |
|---|---|---|
| You own both parent and child | Set an explicit CSP frame-ancestors allowlist on the child, then test the exact parent origin. | Do not weaken framing policy sitewide without understanding clickjacking risk. |
| You own the child but not every parent | Allow only trusted production origins and document the supported embed URL. | Do not use an unrestricted wildcard as a convenience default. |
| You do not own the child | Use an official embed, API, SDK, widget or ordinary link. | Do not strip headers through an unauthorized proxy. |
| You are testing locally | Serve your own files over HTTP on localhost and test the destination's real framing policy. | Do not assume localhost can bypass a third-party SAMEORIGIN rule. |
If you control the framed page
Prefer an explicit CSP rule such as frame-ancestors 'self' https://app.example.com when you need a small allowlist. Remember that the policy must be sent in the HTTP response header. It is not a default-src fallback and cannot be configured through a CSP meta tag.
Why common bypass suggestions fail
- Changing iframe width, height or scrolling: presentation attributes do not affect framing permission.
- Adding CORS headers to the parent: CORS is not the mechanism that grants a page permission to be displayed in an iframe.
- Adding a meta X-Frame-Options tag: the browser expects X-Frame-Options in the framed page's HTTP response.
- Using an old ALLOW-FROM example: ALLOW-FROM is obsolete and is not a dependable modern allowlist.
- Proxying the third-party site: this changes the delivery model, can create serious security and legal problems, and should not be used to defeat another site's policy.
What to do when a third party blocks framing
Look for a documented embed endpoint first. Many providers intentionally block their main application while allowing a separate player, map, widget or public view. If there is no supported embed, consider an API integration, a web component supplied by the provider, or a normal link that opens the destination directly.
Technical references
Common questions
Can JavaScript bypass X-Frame-Options?
No. X-Frame-Options is enforced by the browser based on the framed page's HTTP response. Parent-page JavaScript cannot legitimately override that policy.
Can a meta tag remove X-Frame-Options?
No. X-Frame-Options is an HTTP response header. Adding a meta element to the parent page does not change the framed server's response policy.
What should I do if I own the site that is being framed?
Configure the destination's response headers intentionally. Use CSP frame-ancestors for a modern allowlist and keep a compatible X-Frame-Options value only when your browser support requirements justify it.
What if I do not control the blocked website?
Use the provider's official embed, API or widget if one exists. Otherwise link to the page or ask the owner for an approved integration. Do not proxy third-party content merely to strip security headers.