What is the most critical security vulnerability for .onion services?

SSRF (Server-Side Request Forgery) - application-level vulnerabilities that cause the server to make outbound HTTP requests to attacker-controlled or external IPs. This directly leaks the server's real IP address, deanonymizing the hidden service. Test all URL-accepting inputs for SSRF.

How often should I audit my .onion service's security?

Major security audit: annually or after significant application changes. Automated vulnerability scanning: weekly. Log review for anomalies: daily. Configuration drift check: monthly. Key rotation (Tor introduction keys are automatic, but application secrets): annually or after team membership changes.

Should I allow external security researchers to audit my .onion service?

For services with significant user trust, consider running a responsible disclosure program or formal security audit by third parties. Public bug bounty programs for .onion services are unusual but feasible for high-value services.

What penetration testing tools work against .onion services?

Most web application security tools support SOCKS5 proxy configuration and can be routed through Tor. Burp Suite, OWASP ZAP, and nikto all support proxy configuration. Configure tool's proxy settings to 127.0.0.1:9050 (Tor SOCKS5) before testing .onion targets. Run tests from a separate server with a Tor client, not from the hidden service's own server.

How do I verify that my .onion service is not leaking IP addresses?

Use an external Tor client to access your service. Check HTTP response headers for any IP addresses. Submit controlled input with webhook URLs (requestbin.com type services accessed via Tor) to test for SSRF. Review application logs for any external HTTP requests the application itself initiates. Use Wireshark on the server's network interface to confirm no traffic exits except through Tor.

Security Auditing .onion Hidden Services: Complete Checklist

Security auditing a Tor hidden service requires evaluating multiple layers: the Tor configuration itself, the web application and application server, the underlying operating system, and the operational security practices of the operator. A vulnerability in any layer can undermine the anonymity and security of the entire service. This guide provides a systematic audit checklist for .onion service operators and security professionals assessing hidden service security.

Need this done for your project?

We implement, you ship. Async, documented, done in days.

Start a Brief

Tor Configuration Audit

Audit the torrc configuration for security best practices. Verify HiddenServiceDir permissions are 700 (owner: tor user, group: tor user, no world access). Check for DataDirectory and HiddenServiceDir on encrypted volumes. Verify Tor is running as the tor user, not root (User tor in systemd unit file). Confirm SocksPort is bound to 127.0.0.1, not 0.0.0.0. Verify that hidden service HiddenServicePort maps to a local address (127.0.0.1) rather than an external IP. Check that the Tor process is isolated from the application process - run application as a separate user with no read access to /var/lib/tor/. Review the Tor version for known vulnerabilities and verify it is current. Ensure DisableDebuggerAttachment is 1 to prevent ptrace from other processes.

Web Application Security Assessment

Application layer vulnerabilities are the most common cause of .onion service deanonymization. Test for SSRF (Server-Side Request Forgery): submit URLs as input and verify the application does not make outbound HTTP requests to external IPs that would reveal the server's real IP. This is particularly critical in applications that render user-provided content, process URLs for previews, or handle image/file uploads. Test for XXE (XML External Entity) injection in any XML processing. Test for command injection in any shell-level operations. Verify the application does not log client IP addresses (they are all 127.0.0.1, so logging provides no value and wastes disk space). Verify the application does not include any external resources (fonts, analytics, CDN libraries) in pages - external resource requests reveal the client's IP to the external server.

Server Hardening Verification

Verify OS-level hardening: firewall rules allowing only Tor ORPort and application port from localhost, no other listening ports (check with ss -tlnp). Verify no clearnet-accessible ports: the server should have no public-facing web ports, SSH should be key-only with non-standard port or restricted source IP. Verify full disk encryption is configured (LUKS on Linux) and the decryption passphrase is not stored on the server. Verify automatic security updates are configured. Review installed packages for unnecessary services (remove mailserver, FTP, or other unused daemons). Verify file integrity with AIDE or Tripwire baseline comparison to detect unauthorized changes. Check for world-readable sensitive files: find /var/lib/tor -maxdepth 2 -perm /o+r should return no output.

Application Information Disclosure Check

Review HTTP response headers for information disclosure. Nginx default headers (Server: nginx/1.24.0) reveal server software version. Configure server_tokens off in Nginx to reduce header verbosity. Check for application framework version disclosure in response headers or error pages. Verify error pages return generic messages rather than stack traces or database error details. Review the application for features that might disclose the server's IP: server-side HTTP redirects to external URLs, email sending functionality (SMTP From header reveals server hostname), PDF generation tools that make external HTTP requests for embedded resources. Audit all user-supplied content rendering paths for SSRF and content injection vulnerabilities that could cause the server to contact external IPs.

Operational Security Review

Operational security audit covers human and procedural factors. Review access control: how many people have SSH access to the server, are all keys documented and revocable, when did each key last successfully authenticate? Review secret management: are API keys, database passwords, and encryption keys stored securely (environment variables or secrets managers) rather than in version-controlled code? Review monitoring: is there an alerting system that would notify operators of server compromise (file integrity changes, unexpected process launches, Tor daemon failures)? Review backup security: are backups encrypted before storage, are backup access credentials separate from production credentials, when was the backup last tested for restoration? Review incident response: is there a documented procedure for responding to suspected compromise of the hidden service?

Related Services

Offshore VPS from $17.90/mo Dedicated Servers DevOps Services

Why Anubiz Host

100% async — no calls, no meetings

Delivered in days, not weeks

Full documentation included

Production-grade from day one

Security-first approach

Post-delivery support included

Bulletproof Hosting Providers

DMCA-Ignored Servers

Offshore VPS Hosting

Anonymous Hosting Solutions

Ready to get started?

Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.

Start a Brief Tor Hosting Basic