Add support for user-defined <iframe> origins via Content-Security-Policy #118
Unanswered
KazWolfe
asked this question in
Core functionality
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Describe your core improvement
It may be desirable for certain users to embed Home Assistant as an
<iframe>into other applications, such as wall tablets, SSO providers, or as integrations with other dashboard solutions. This can be done with a theoretical configuration:This will then generate a
Content-Security-Policyallowing these frames. For compatibility, it also would make sense to continue shippingX-Frame-Optionsfor legacy browsers that may not support CSP.As (modern) browsers will ignore
X-Frame-Optionsifframe-ancestorsis set, only the specified origins will be permitted.Users constrained to legacy browsers that understand
X-Frame-Optionsbut not CSP'sframe-ancestors(a very small subset) would still be able to disableX-Frame-Optionsvia the already-existinguse_x_frame_optionsheader.Current limitations
At present, this can only be done by setting
http.use_x_frame_optionstofalse, allowing Home Assistant to embedded by anybody. This, in turn, re-opens the security vulnerability that this feature aimed to close.Technical benefits
This allows users more control over when and where
iframes can be embedded based on their own risk profiles, and prevents re-opening the full security hole exposed by disablingX-Frame-Optionsoutright.This could (may?) also be used as a launch point to support even more Content-Security-Policy settings through different schemas, e.g.:
Additional context
I'd be happy to take a stab at implementing this via PR, assuming certain design considerations are solidified in a way that satisfies project requirements.
Beta Was this translation helpful? Give feedback.
All reactions