Home Assistant security concern

XSS - Cross-Site Scripting

CSV Injection

SQL Injection

Command Injection

ORM Injection

FTP Injection

XXE - XML eXternal Entity

CSRF - Cross-Site Request Forgery

SSRF - Server-Side Request Forgery






Sub Domain Enumeration


Web Shell










Remote Code Execution


SQL Injection

NoSQL Injection

FTP Injection



Header Injection



Browser Exploitation

Frontend (like CSP bypass, URL spoofing, and something like that)

Backend (core of Browser implementation, and often refers to C or C++ part)





  • prowler - Tool for AWS security assessment, auditing and hardening by @Alfresco.
  • A2SV - Auto Scanning to SSL Vulnerability by @hahwul.


OSINT - Open-Source Intelligence

Sub Domain Enumeration

Code Generating




XSS - Cross-Site Scripting

  • XSStrike - XSStrike is a program which can fuzz and bruteforce parameters for XSS. It can also detect and bypass WAFs by @UltimateHackers.
  • xssor2 - XSS’OR - Hack with JavaScript by @evilcos.

SQL Injection

  • sqlmap - Automatic SQL injection and database takeover tool.

Template Injection

  • tqlmap - Code and Server-Side Template Injection Detection and Exploitation Tool by @epinna.



  • sqlchop - SQL injection detection engine by chaitin.
  • xsschop - XSS detection engine by chaitin.
  • retire.js - Scanner detecting the use of JavaScript libraries with known vulnerabilities by @RetireJS.
  • malware-jail - Sandbox for semi-automatic Javascript malware analysis, deobfuscation and payload extraction by @HynekPetrak.
  • repo-supervisor - Scan your code for security misconfiguration, search for passwords and secrets.
  • bXSS - bXSS is a simple Blind XSS application adapted from cure53.de/m by @LewisArdern.
  • OpenRASP - An open source RASP solution actively maintained by Baidu Inc. With context-aware detection algorithm the project achieved nearly no false positives. And less than 3% performance reduction is observed under heavy server load.


  • js-xss - Sanitize untrusted HTML (to prevent XSS) with a configuration specified by a Whitelist by @leizongmin.


  • Charles - HTTP proxy / HTTP monitor / Reverse Proxy that enables a developer to view all of the HTTP and SSL / HTTPS traffic between their machine and the Internet.
  • mitmproxy - Interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers by @mitmproxy.





  • Dnslogger - DNS Logger by @iagox86.
  • CyberChef - The Cyber Swiss Army Knife - a web app for encryption, encoding, compression and data analysis - by @GCHQ.

That’s good, but I was thinking something more to highlighting the common mistakes that have happened.
Like the samba add-on, x-forward, password leak with github…
Trying to concentrate some knowledge instead of being lost in different posts.

1 Like

Thanks that’s some great material for further reading :+1:

This reading makes you even more paranoid with security. :smiley:

That is the basic idea of things. That way you can have multiple stuff in different folders like if you want to point /mymodem to your http interface of your cable modem you could. It would be wrapped in HTTPS then you could do a user ID/password as well. You could also run your own fail2ban filters as well for brute force checking. The one downside I found to HA was you couldn’t do a base URL on it like other apps that you can use with a reverse proxy. This put the HA login front line and center for some pen testing unlike say another app you put at /SDJ39SJ9JSJD-JDFI3JSCNSJS9JD or whatever other long location name you wanted. It’s a little bit of security by obscurity but someone would have to know that long URL to even begin beating on your login to figure out the user/password combo.

It isn’t only for serving multiple servers. It’s about what you trust as your front door.

HA is a very complex project that has access to a huge number of services and devices within your home. It’s only trivially protected by a single password. Even if you assume that HA has no backdoors or bugs that allow access, that’s like leaving your important documents filing cabinet out in the open. Even if the filing cabinet is secure, everyone will see it’s there and every bump goes directly to it.

Putting a reverse proxy in front, whether it be haproxy/nginx/apache limits your attack surface by effectively putting that file cabinet inside a room with a door. That door is now what everything has to go through to get to your file cabinet. Even if you accidentally left the cabinet open, like if you accidentally forgot to set a password on your HA instance, people still have to get through the door first. Alternatively, even if the cabinet was broken and had a hole in the back(i.e. has a horrible security bug), well it wouldn’t matter because people still have to go through the door, and they wouldn’t even know about the cabinet unless they got through the door first.

Now you can easily set up the proxy poorly, in effect leaving the door wide open and you gain no protection at all. But It is much easier to set up properly since it only does ONE thing, making it a much smaller attack surface, and more importantly, proxies are designed with access control in mind as a primary function. This means I would generally trust my proxy to be better at access control than an app like HA where access control is a secondary priority compared to functionality, and there are multiple methods of authenticating (password/api/token/headers etc etc) that need to be tested and protected.


Great post, hope you got it in a onenote or something similar :slight_smile:

Just for clarification I have Hassio and samba add on with guest activated and no password on Samba, but on Home Assistant. I haven’t opened any ports myself, but do have a Google Wifi router with UPNP activated. Does this then mean I unintentionally have opened my installation for everyone looking?

What is/are the preferred configuration(s) if I wish to utilize Amazon Echos or Google Homes with Home Assistant? Using these devices are the primary reason I have my Home Assistant instance exposed to the internet.

I only have port 443 forwarded to HA and UPNP is disabled. Guest SMB access is disabled. I don’t use the HA Cloud service. I’d like to continue to use Google Home and Amazon Echo, but would like greater security than one password for HA.

I know enough about network security to know that I don’t know enough about network security, It seems seeing up Nginx would be preferred, but that would break the Google and Amazon integrations. Is this correct? Before integrating these services, I would only access HA via a VPN into my network.

Any advice on beefing up my security while still using Google Home and Alexa? Thanks.

If you use HA cloud for Google Home and Alexa there is no need to open any ports as far as I know.

1 Like

In theory this might be the case. But you should realize it’s not just Hassio Samba addon which could open ports. If UPnP is enabled any device or program (including mailware, etc.) could compromise the security of your network.

See Guide : OpenVPN Access to Home Assistant

And as @sjee has said for HA cloud and Google Assistant Cloud


Disable UPnP.

I would like to do that, but it seems like a Chromecast cannot work without it.

There is no reason for a Chromecast to need to open any ports.

I tried yesterday to deactivate UPnP and that seems to render the Chromecats unusable. It also seems like it in Google’s docs:

“Learn More: Router has UPnP disabled
UPnP (Universal Plug and Play), also known as multicast, allows for the discovery of UPnP enabled devices on the same Wi-Fi network.

It appears that you have UPnP disabled on your router. This makes Chromecast undiscoverable”


UPNP isn’t multicast…and I don’t have UPNP enabled on my router, and my Chromecasts work just fine.

UPnP isn’t just for “opening the ports” and UPnP discovery part of the protocol does use multicast. So depending on your network topology, you many need to have multicast enabled on the router in order for UPnP to work. Usually it is not a problem, when all devices are on the same network subnet.

yes, but I was referring to this inaccuracy (Google’s fault) of saying that UPnP is ALSO known as multicast…that is inaccurate

Thanks everyone for the explanation on the reverse proxy setup. I’ve now moved mine over to caddy.

Can anyone see any issues with the following config? (the homeassistant caddy config is pretty basic).

https://xxx.duckdns.org {
header / {
Strict-Transport-Security “max-age=31536000; includeSubdomains”
X-XSS-Protection “1; mode=block”
X-Content-Type-Options “nosniff”
X-Frame-Options “SAMEORIGIN”
Referrer-Policy “same-origin”
tls …/xxx …/xxx
proxy / localhost:8123 {
header_upstream Host {host}
header_upstream X-Real-IP {remote}
header_upstream X-Forwarded-For {remote}
header_upstream X-Forwarded-Proto {scheme}

https:// {
tls self_signed
status 403 /

Basically still using my own scripted Lets Encrypt certs rather than using caddy, mainly because I have my router scripted to open port 80 to HA when the cert is renewed, and then closed afterwards. Would rather not leave it permanently open for caddy. Caddy is also issuing a fake cert if users dont know my domain name and try to use IP address.

I also have caddy set to overwrite the X-Forwards-For header to the clients address to prevent faking of the clients IP address.

I am then using X-Forwards-For=true in configuration.yaml. I have tested curl with X-Forwards-For set to a fake address and it is replaced by the clients actual address. This means my fail2ban will still work.

With all of that taken into account, is it safe then to use X-Forwards-For and Trusted Networks together in HA?