Trust & Security

HLE is a relay service — your traffic passes through the HLE server to provide SSO authentication and subdomain routing. Transparency matters — here’s what that means for your data.

Architecture

Your Service ←→ HLE Client ←→ [TLS] ←→ HLE Relay ←→ [TLS] ←→ End User
                (your network)          (HLE server)          (browser)

The HLE relay terminates TLS to read HTTP headers for authentication and subdomain routing. This is a standard reverse-proxy architecture — the same approach used by Cloudflare Tunnel, Ngrok, and similar services. Because TLS is terminated at the relay, request data (headers, bodies, URLs) passes through server memory during proxying.

What HLE Logs

HLE logs security events, not traffic content. Every login, tunnel connection, access gate decision, and billing event is recorded with timestamps and IP addresses.

What’s logged	Details captured
Account events	Login, registration, password changes, SSO linking — with IP and timestamp
Tunnel events	Connected, disconnected, access rule changes, PIN/auth config changes
Access gate	Per-visitor decisions: IP, user agent, auth method used, allowed/denied
Traffic metrics	Byte counts, request counts, latency — never URLs, headers, or bodies

What HLE never stores

The relay proxies your traffic content in memory only — nothing below is ever written to disk:

• Request/response bodies
• URL paths — the relay routes by subdomain; full paths are forwarded to your service but never logged
• Application headers and cookies — auth tokens, custom headers, and session cookies pass through memory but are never persisted
• File contents, form data, or API payloads
• WebSocket message contents

What IS stored

Access gate metadata (IP, user agent, auth decision) is written to disk — that’s what powers the access logs, CSV exports, and per-plan retention described below. This is access control data, not traffic content, The distinction matters: this is access control data, not traffic content.

Important context

Like any reverse proxy that terminates TLS, the relay sees your traffic in memory while forwarding it. HLE doesn’t store, log, or inspect application-level content — but it does transit the HLE relay in memory. If this is a concern for your threat model, the client source code is fully auditable.

Tip

The HLE client is MIT-licensed open source. You can inspect exactly what data leaves your network.

Encryption

• Client to relay: TLS 1.2+ (WebSocket over HTTPS)
• Relay to end user: TLS 1.2+ with Let’s Encrypt certificates
• Passwords: PBKDF2-SHA256 with 600,000 iterations (OWASP recommendation)
• API keys: Stored as SHA-256 hashes (plaintext never persisted)
• JWTs: HS256 signed, HTTP-only SameSite=Lax cookies, 24h expiry

Rate Limiting & Abuse Prevention

• Login: 10 attempts per IP per 5 minutes
• Registration: 3 attempts per IP per 5 minutes
• Account lockout: Progressive backoff after 5 failed logins (60s, doubling up to 1 hour)
• reCAPTCHA v3 on registration (when configured)

Tunnel Access Control

Every tunnel is protected by default. The owner controls who can access it:

Method	Description	Plans
SSO allow-list	Email + provider rules (Google, GitHub, any)	All
PIN	4-8 digit numeric code	All
HTTP Basic Auth	Username/password enforced at relay	All
Share links	Temporary signed URLs with expiry	All: up to 7 days, 100 active
Public mode	No authentication (--auth none)	All

Audit Logging & Data Retention

Administrative actions (user management, API key operations, setting changes, access rule modifications) are logged separately with timestamps, user identity, and action details.

Data retention by plan

Data	Free	PAYG
Access log retention	7 days	Up to 30 days
Export logs (CSV)	—	Yes
Disable access logging	—	Yes
IP allowlist per tunnel	—	Yes

Open Source

The HLE client is fully open source under the MIT license:

• hle-client — CLI client and shared protocol library
• ha-addon — Home Assistant add-on
• hle-docker — Docker distribution

Security Scanning

Per-commit (every push and PR)

• Semgrep — Static application security testing (SAST)
• Bandit — Python-specific security linting
• pip-audit — Python dependency vulnerability scanning
• npm audit — Frontend dependency scanning
• TruffleHog — Secret detection in commits
• Gitleaks — Git history secret scanning

Periodic (nightly and on-demand)

• OWASP ZAP — Dynamic application security testing (DAST)
• Nuclei — Network vulnerability scanning
• Trivy — Container image vulnerability scanning
• TestSSL/SSLyze — TLS configuration testing

Abuse handling

HLE is a relay: tunnels and the services behind them are operated by individual users. When a tunnel is used for phishing, malware, spam or other content that breaks the Terms, we act on it.

• Report abuse through the public abuse form or by email to abuse@hle.world.
• Child sexual abuse material is reported to NCMEC and the IWF.
• Takedowns suspend the tunnel immediately. The hostname stops routing and its reservation is kept so it cannot simply be re-registered; every action is recorded in the audit log.
• Subdomain labels that impersonate well-known brands are refused at registration; a tunnel already using one under an earlier policy is grandfathered and flagged for review.

A report you submit on the form may include an optional email address so we can follow up; it is used for nothing else and is visible to HLE staff only.

GDPR & Privacy

HLE processes IP addresses under GDPR Article 6(1)(f) — legitimate interest for security and abuse prevention. See the full Privacy Policy for details.

You have the right to:

• Access your data (visible in your dashboard)
• Delete your account and all associated data (contact hello@hle.world)
• Export your access logs (PAYG plan, CSV from dashboard)
• Object to processing (contact hello@hle.world)

Responsible Disclosure

Found a security vulnerability? Please report it responsibly:

• Email: security@hle.world (see also /.well-known/security.txt)
• Do not open public GitHub issues for security vulnerabilities
• HLE will not take legal action against good-faith security researchers