Hidden Service Security Audit Checklist for 2026

Clearnet leakage is the highest severity hidden service vulnerability. It occurs when the application or server makes outbound requests to clearnet addresses, revealing the server IP to the request destination. Test for this with the following method:

Set up a simple HTTPS logging server on a clearnet IP you control. Configure it to log all incoming requests including source IP. From the hidden service application, trigger every feature that might make external requests: user avatar loading, external link previews, email validation via MX lookup, third-party authentication callbacks, CDN-hosted resources, and update checks. If any requests appear in your logging server from an IP that is not a Tor exit node, you have clearnet leakage.

Confirm iptables rules are blocking outbound clearnet traffic from all non-tor processes: iptables -L OUTPUT -v -n. The rule allowing outbound traffic only for uid debian-tor should be visible. Test by attempting an outbound connection from the application user: sudo -u www-data curl http://1.1.1.1. This should fail with connection refused or permission denied.

HTTP response headers frequently disclose server software, versions, framework identifiers, and other information useful to fingerprinting attackers. Audit all headers from your hidden service with: curl -I http://YOUR_ONION_ADDRESS/ -x socks5h://127.0.0.1:9050

Headers to remove or neutralize:

Server: nginx/1.24.0  - Reveals server software and version
X-Powered-By: Express - Reveals application framework
Via: - Reveals proxy chain
X-Generator: - Reveals CMS platform
X-Drupal-Cache: - Reveals CMS type
X-WordPress-Cache: - Same
X-Varnish: - Reveals caching infrastructure

Set server_tokens off in nginx or header -Server in Caddy. Remove application-level headers in the application's response middleware. Run a second curl check after changes to verify all identifying headers are removed. Check for headers added by intermediate components like application servers, caching layers, and Node.js frameworks separately.

Web server misconfiguration frequently exposes sensitive files and directories. Check for common exposure points:

curl http://YOUR_ONION_ADDRESS/.git/config -x socks5h://127.0.0.1:9050
curl http://YOUR_ONION_ADDRESS/.env -x socks5h://127.0.0.1:9050
curl http://YOUR_ONION_ADDRESS/wp-config.php -x socks5h://127.0.0.1:9050
curl http://YOUR_ONION_ADDRESS/config.php -x socks5h://127.0.0.1:9050
curl http://YOUR_ONION_ADDRESS/backup.sql -x socks5h://127.0.0.1:9050
curl http://YOUR_ONION_ADDRESS/server-status -x socks5h://127.0.0.1:9050

All of these should return 404 or 403. A 200 response from .git/config reveals your git repository structure and potentially commit history including credential changes. A 200 from .env exposes application configuration secrets. A 200 from server-status reveals server performance metrics and active request paths.

Block sensitive file patterns in nginx with explicit deny rules: location ~* /.(git|env|htaccess|htpasswd|DS_Store) { deny all; }. Verify the block is effective with curl after adding the rule.

Verify each service component runs with minimum required privileges. Check running processes and their users: ps aux | grep -E "tor|nginx|caddy|node|postgres|redis". The output should show tor running as debian-tor, nginx workers as www-data, the application as a dedicated app user, and postgres as postgres. Root processes should be limited to system management.

Check file permissions on sensitive directories: ls -la /var/lib/tor/hidden_service/. The directory should be owned by debian-tor with permissions 700, and the files inside with permissions 600. Looser permissions allow other system users to read your onion private key.

Verify systemd security settings for each service: systemctl show tor nginx caddy --property=PrivateTmp,ProtectSystem,NoNewPrivileges,CapabilityBoundingSet. Services should have PrivateTmp=true, ProtectSystem=strict, and NoNewPrivileges=true at minimum. Missing these restrictions leaves services exposed to privilege escalation through application vulnerabilities.

Verify no services listen on public network interfaces. Run: ss -tlnp and look for services listening on 0.0.0.0 or specific public IPs rather than 127.0.0.1 or ::1. For a properly configured hidden service, nginx/Caddy, Node.js, PostgreSQL, and Redis should all show only 127.0.0.1 as listening address. Only SSH (port 22 or your custom port) and Tor's ORPort should have external listeners.

Verify the iptables configuration blocks direct server access on all ports except SSH: iptables -L INPUT -v -n. Any port other than SSH that accepts input from non-Tor sources creates a potential deanonymization vector if the hidden service infrastructure can be correlated with the server through traffic analysis.

Check for DNS leaks. The application should not be making DNS queries for external domains: tcpdump -i any port 53 -n. Watch for any DNS queries while triggering all application features. DNS queries for external domains indicate the application is attempting clearnet access, which may succeed even if TCP is blocked (some DNS resolvers are accessible through UDP on port 53 even with TCP blocking rules).