SelfHostedSecurityReview
title: Self-Hosted Application Security Review type: technique created: 2026-05-21 last_updated: 2026-05-21 related: ["radar/techniques/DockerSecuritySelfHosting", "radar/techniques/PackerProxmoxTemplates"] sources: ["https://github.blog/2023-11-30-securing-our-home-labs-home-assistant-code-review/"] radar_quadrant: Techniques radar_ring: Assess radar_position: inner
A technique for evaluating the security posture of self-hosted web applications, derived from GitHub Security Lab's 2023 code review of Home Assistant — one of the most widely deployed self-hosted IoT platforms.
GitHub Security Lab's review identified several vulnerability classes that recur across self-hosted applications:
Server-Side Request Forgery (SSRF). Self-hosted applications often accept user-supplied URLs for integrations (webhooks, API endpoints, device discovery). Without validation, these become SSRF vectors — allowing attackers to probe internal network services. Mitigation: validate and allowlist URL schemes and host ranges; block RFC 1918 addresses.
Path traversal. File management features (backup restore, plugin loading, log viewing) that accept user-supplied paths without normalisation allow directory traversal. Mitigation: canonicalise all paths and validate they remain within the intended root.
Insecure deserialization. Configuration files and plugin manifests parsed from user-controlled input (YAML, JSON, pickle) are common injection points. Mitigation: use safe deserialisation libraries; avoid eval() and pickle.loads() on untrusted input.
Privilege escalation via integrations. Third-party plugins or integrations run with the same privileges as the host application. A malicious or compromised plugin can access all data and secrets the application can access. Mitigation: plugin sandboxing; principle of least privilege for integration credentials.
Unauthenticated endpoints. Internal APIs intended for local network access are often not authenticated, assuming network access implies trust. When exposed via reverse proxy or misconfigured firewall, these become unauthenticated remote endpoints. Mitigation: authenticate all endpoints regardless of assumed network context.
The vulnerability classes above are not Home Assistant-specific. They appear in any self-hosted application that:
- Accepts user-supplied URLs or file paths
- Supports plugins or integrations
- Parses configuration from user-controlled files
- Exposes internal APIs assumed to be LAN-only
A self-hosted security review checklist should probe all five categories as a minimum, regardless of the application being reviewed.
radar/techniques/DockerSecuritySelfHosting addresses container-layer hardening (network isolation, capability dropping, socket protection). This blip addresses application-layer vulnerabilities. The two are complementary: Docker hardening limits blast radius; application security review prevents initial compromise.
Self-Hosted Application Security Review sits in the Assess ring of the Techniques quadrant, at inner position. First studied via the GitHub Blog (2023-12-01). The Home Assistant review provides a concrete, public case study of vulnerability classes that appear across the self-hosted ecosystem. Inner position reflects immediate applicability to any self-hosted service exposed to the internet or an untrusted local network — particularly relevant alongside the DockerSecuritySelfHosting and PackerProxmoxTemplates blips already on the radar.
