FIDO2 WebAuthn frame no longer loads in Web Vault #1026

New Issue

OVERLORD · 2025-10-09T17:01:18+03:00

OVERLORD commented

2025-10-09 17:01:18 +03:00

Originally created by @ducmthai on GitHub.

FIDO2 WebAuthn prompt frame does not load

The iframe is saying my-selfhost-vault.com refused to connect. my-selfhost-vault.com is served through Cloudflare

Deployment environment

vaultwarden version: 1.26-alpine

Install method: docker
Clients used: web vault
Reverse proxy and version: nginx 1.18
MySQL/MariaDB or PostgreSQL version: N/A
Other relevant details: Cloudflare -> nginx -> vaultwarden docker

Steps to reproduce

Setup a Yubikey as FIDO2 WebAuthn 2fa, then login via webvault

Expected behaviour

The FIDO2 WebAuthn page should prompt for a toutch/tap the security key.

Actual behaviour

The iframe where /images/u2fkey.webp is usually showed just says my-selfhost-vault.com refused to connect.

Troubleshooting data

1.25.0-alpine works with /webauthn-connector.html?data=<token> has x-frame-options: SAMEORIGIN in its response header. 1.26.0-alpine does not have this header.

1.26.0

1.25.0

Originally created by @ducmthai on GitHub.   ### FIDO2 WebAuthn prompt frame does not load The iframe is saying `my-selfhost-vault.com` refused to connect. `my-selfhost-vault.com` is served through Cloudflare ### Deployment environment     * vaultwarden version: 1.26-alpine  * Install method: docker * Clients used: web vault * Reverse proxy and version: nginx 1.18 * MySQL/MariaDB or PostgreSQL version: N/A * Other relevant details: Cloudflare -> nginx -> vaultwarden docker ### Steps to reproduce Setup a Yubikey as FIDO2 WebAuthn 2fa, then login via webvault ### Expected behaviour The FIDO2 WebAuthn page should prompt for a toutch/tap the security key. ### Actual behaviour The iframe where `/images/u2fkey.webp` is usually showed just says `my-selfhost-vault.com` refused to connect. ### Troubleshooting data `1.25.0-alpine` works with `/webauthn-connector.html?data=<token>` has `x-frame-options: SAMEORIGIN` in its response header. `1.26.0-alpine` does not have this header. ### 1.26.0 ![1 26 0](https://user-images.githubusercontent.com/13193688/196568071-399adf9e-cbf9-4415-96e5-c5636432c573.png) ### 1.25.0 ![1 25 0](https://user-images.githubusercontent.com/13193688/196568077-817da357-a88e-46f2-9022-18cdc64efb53.png)

OVERLORD closed this issue

2025-10-09 17:01:20 +03:00

OVERLORD commented

2025-10-09 17:01:21 +03:00

@ducmthai commented on GitHub:

Adding add_header X-Frame-Options "SAMEORIGIN"; to nginx.conf fixed the issue.

@ducmthai commented on GitHub: Adding `add_header X-Frame-Options "SAMEORIGIN";` to nginx.conf fixed the issue.

OVERLORD commented

2025-10-09 17:01:22 +03:00

@BlackDex commented on GitHub:

Just as a follow-up.
All the correct headers are already sent by Vaultwarden, including that one. There are probably other headers which you may overrides out not. I suggest to not override any header and keep most of these as is.

Also, using this setting will probably break the desktop client.

@BlackDex commented on GitHub: Just as a follow-up. All the correct headers are already sent by Vaultwarden, including that one. There are probably other headers which you may overrides out not. I suggest to not override any header and keep most of these as is. Also, using this setting will probably break the desktop client.

OVERLORD commented

2025-10-09 17:01:22 +03:00

@ducmthai commented on GitHub:

Just as a follow-up. All the correct headers are already sent by Vaultwarden, including that one. There are probably other headers which you may overrides out not. I suggest to not override any header and keep most of these as is.

Also, using this setting will probably break the desktop client.

Hmm, if so, I wonder why 1.25 works and 1.26 doesn't.

Update: I just tried 1.25/1.26 without the header override and Desktop client still does not load the frame. This time I also skipped Cloudflare through DNS rewrite.

Additional errors in DevTools of the Desktop Client:

For 1.25:

Refused to frame 'https://my-selfhosted-vault.com/' because an ancestor violates the following Content Security Policy directive: "frame-ancestors 'self'

For 1.26 (Same error with webvault)

Refused to display 'https://my-selfhosted-vault.com/' in a frame because it set 'X-Frame-Options' to 'deny'.

Update 2: I do have this in my nginx.conf.

# Disallow the site to be rendered
add_header X-Frame-Options "DENY";

I gave this header value "ALLOW" for vaultwarden so that the client would ignore it and it works.

@ducmthai commented on GitHub: > Just as a follow-up. All the correct headers are already sent by Vaultwarden, including that one. There are probably other headers which you may overrides out not. I suggest to not override any header and keep most of these as is. > > Also, using this setting will probably break the desktop client. Hmm, if so, I wonder why 1.25 works and 1.26 doesn't. **Update**: I just tried 1.25/1.26 without the header override and Desktop client still does not load the frame. This time I also skipped Cloudflare through DNS rewrite. Additional errors in DevTools of the Desktop Client: ### For 1.25: `Refused to frame 'https://my-selfhosted-vault.com/' because an ancestor violates the following Content Security Policy directive: "frame-ancestors 'self'` ### For 1.26 (Same error with webvault) `Refused to display 'https://my-selfhosted-vault.com/' in a frame because it set 'X-Frame-Options' to 'deny'.` **Update 2**: I do have this in my nginx.conf. ``` # Disallow the site to be rendered add_header X-Frame-Options "DENY"; ``` I gave this header value "ALLOW" for vaultwarden so that the client would ignore it and it works.

OVERLORD referenced this issue

2025-10-09 18:25:31 +03:00

[PR #1026] [MERGED] Fixes #1022 cloning with attachments #3552

OVERLORD referenced this issue

2025-10-09 18:25:33 +03:00

[PR #1026] Fixes #1022 cloning with attachments #3555

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#1026