I’ve just purchased a HIBP api key and entered it in the relevant field of the Admin page, but I can’t get the Exposed Password report to run; the status symbol just continues to swirl continuously.
Also, if I try to change my password and select “Check known data breaches for this password” before clicking on “change master password”, nothing happens (the process silently fails, as per my previous post).
Is there something else I need to be doing to get the report to work using my HIBP api key?
Check the browser developer tools (F12) and what happens there in the console and network tabs.
Ok, this is obviously the issue, but what does it mean…?
Refused to connect to https://api.pwnedpasswords.com/range/XXXXX because it does not appear in the connect-src directive of the Content Security Policy.
That means you configured your reverse proxy incorrectly.
Vaultwarden sets all the needed security headers as strict as possible.
See vaultwarden/src/util.rs at 753a9e0baee3ba3e7b4e05f18d3259e010b68d62 · dani-garcia/vaultwarden · GitHub
Your reverse proxy probably overwrites them.
Thanks for identifying the problem for me.
I use Nginx as a reverse proxy… do you have any idea what I need to change/how I need to change it to fix this?
This is my current Nginx configuration under sites-enabled:
# You should look at the following URL's in order to grasp a solid understanding
# of Nginx configuration files in order to fully unleash the power of Nginx.
# https://www.nginx.com/resources/wiki/start/
# https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/
# https://wiki.debian.org/Nginx/DirectoryStructure
#
# In most cases, administrators will remove this file from sites-enabled/ and
# leave it as reference inside of sites-available where it will continue to be
# updated by the nginx packaging team.
#
# This file will automatically load configuration files provided by other
# applications, such as Drupal or Wordpress. These applications will be made
# available underneath a path with that package name, such as /drupal8.
#
# Please see /usr/share/doc/nginx-doc/examples/ for more detailed examples.
##
# Default server configuration
#
#server {
# listen 8181 default_server;
# listen [::]:8181 default_server;
# SSL configuration
#
# listen 443 ssl default_server;
# listen [::]:443 ssl default_server;
#
# Note: You should disable gzip for SSL traffic.
# See: https://bugs.debian.org/773332
#
# Read up on ssl_ciphers to ensure a secure configuration.
# See: https://bugs.debian.org/765782
#
# Self signed certs generated by the ssl-cert package
# Don't use them in a production server!
#
# include snippets/snakeoil.conf;
# root /var/www/html;
# Add index.php to the list if you are using PHP
# index index.html index.htm index.nginx-debian.html;
# server_name _;
# location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
# try_files $uri $uri/ =404;
# }
# pass PHP scripts to FastCGI server
#
#location ~ \.php$ {
# include snippets/fastcgi-php.conf;
#
# # With php-fpm (or other unix sockets):
# fastcgi_pass unix:/run/php/php7.4-fpm.sock;
# # With php-cgi (or other tcp sockets):
# fastcgi_pass 127.0.0.1:9000;
#}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
# deny all;
#}
#}
# Virtual Host configuration for example.com
#
# You can move that to a different file under sites-available/ and symlink that
# to sites-enabled/ to enable it.
#
#server {
# listen 8181;
# listen [::]:8181;
#
# server_name <VAULT_URL>;
#
# root /var/www/<VAULT_URL>;
# index index.html;
#
# location / {
# try_files $uri $uri/ =404;
# }
#}
upstream vaultwarden-default {
zone vaultwarden-default 64k;
server 127.0.0.1:8181;
keepalive 2;
}
map $http_upgrade $connection_upgrade {
default upgrade;
'' "";
}
server {
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
server_name <VAULT_URL>; # managed by Certbot
client_max_body_size 525M;
location / {
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://vaultwarden-default;
}
# Optionally add extra authentication besides the ADMIN_TOKEN
# Remove the comments below `#` and create the htpasswd_file to have it active
#
#location /admin {
# # See: https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-basic-authentication/
# auth_basic "Private";
# auth_basic_user_file /path/to/htpasswd_file;
#
# proxy_http_version 1.1;
# proxy_set_header Upgrade $http_upgrade;
# proxy_set_header Connection $connection_upgrade;
#
# proxy_set_header Host $host;
# proxy_set_header X-Real-IP $remote_addr;
# proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# proxy_set_header X-Forwarded-Proto $scheme;
#
# proxy_pass http://vaultwarden-default;
#}
listen [::]:443 ssl; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/<VAULT_URL>/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/<VAULT_URL>/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = <VAULT_URL>) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80 ;
listen [::]:80 ;
server_name <VAULT_URL>;
return 404; # managed by Certbot
}```
Looks ok. You might have something like ModSecurity or WAF enabled globally?
I don’t have ModSecurity/WAF 
It’s a head-scratcher, huh?
Is there anything else I can check/tests I can run?
Something between your browser and Vaultwarden is either changing our removing those headers. You should check all steps.
Thanks for your help, @BlackDex.
I found an Nginx config where I’d added a custom line to address an issue I was having with another site. The issue was no longer a problem, so I removed the problematic config.
Nginx then wouldn’t restart due to a duplicate vaultwarden-upstream line in my Vaultwarden configuration (I have no idea why that was suddenly a problem; I hadn’t touched that config). I removed the duplicate reference and hey presto, everything is now working as it should… including creating accounts and changing passwords!
Thanks again for your help with this!
2 Likes