Secure the application and its administrative access, limit the backend listener, protect onion-service keys and test the publication through a compatible client. Onion routing is one layer of the design. It does not remove application vulnerabilities, mistakes in published content or the need to define who should have access.
Define the publication and its audience
Begin with a lawful publishing purpose and a description of the audience. A public research publication and a restricted project portal have different access requirements. Decide which content is intended to be public, which needs application authentication and which should never reach the web root. Keep those decisions separate from the transport used to reach the site.
Write a small data inventory before deployment: pages, uploads, database content, administrator accounts and service configuration. Assign an owner for updates and incident handling. The fact that a site uses an onion address does not settle retention, content rights or security responsibilities. Those remain practical application decisions that need an explicit operating plan.
Keep the backend listener deliberate
An onion service maps a connection to a local application endpoint. Review where that endpoint listens and what other networks can reach it. The Tor Project's setup guide describes Unix sockets as a useful way to avoid exposing the backend to a local network. Choose an approach supported by your server and verify its actual reachability.
A connection that works through Tor can coexist with an unintended public listener. Test both the intended access path and the boundaries around the backend. Avoid generic configuration assumptions; read the application's listening settings and the web server's virtual-host routing. Keep management interfaces distinct from the publicly intended service and restrict who may change those settings.
Review what the application publishes
Inspect pages, uploaded files, error output and embedded resources as a reader would encounter them. An application can reveal operational details through debugging messages or link to external assets without that being obvious in its main design. Review generated URLs and content metadata. Serve only the resources the publication requires and understand any third-party request it initiates.
For an illustrative research site, review a sample article, attachment and contact page before launch. Verify that a private editorial document and an environment file are outside the public directory. Use non-sensitive test material when checking uploads. A successful onion connection proves reachability; this content review checks what the service actually discloses to its audience.
Treat the service identity as protected material
The onion-service configuration includes key material that must remain private. Keep it outside public website files and limit access to the operators who need it. Plan how a legitimate recovery preserves the intended service identity and how a compromise would be handled. Do not place service keys into a public archive, support message or shared project repository.
Include the application, data and required service configuration in the recovery design, with appropriate protection for each. A backup of site content alone may not restore the intended address, while a copy containing private keys creates a sensitive backup. Document who can decrypt and restore it and test that access without exposing the keys in exercise reports.
Choose public or restricted access explicitly
Application login and Tor client authorisation are different layers. The Tor Project documents client authorisation for making access to a v3 onion service depend on a client credential. Decide whether that model fits the audience and operational process. It is not automatically needed for a public publication and does not replace the application's permissions once a client connects.
Consider a project portal with a small approved group. You need a way to distribute, replace and revoke access material privately, as well as manage application accounts. Test the removal of an authorised client and an application user separately. The following table keeps these controls distinct instead of promising that one setting solves every access problem.
| Control | Question it answers | Separate responsibility |
|---|---|---|
| Backend listener | Who can reach the local application endpoint? | Web server and network configuration |
| Client authorisation | Which clients may connect to the onion service? | Private credential distribution and revocation |
| Application permissions | What may a connected user do? | Account roles and data access |
| Publishing review | What does the site disclose? | Content, uploads and error handling |
Test through the reader's connection
Use a compatible client to test pages, navigation, forms and downloads through the intended onion access path. Observe errors and application resource use with harmless test traffic. Avoid measuring only a local backend request, because it does not exercise the reader's full connection. Keep test accounts and any restricted-access credentials private.
Check recovery and maintenance procedures as well. An application update should have a rollback point and a way to validate the onion route afterwards. Define useful operational logs and retention without assuming that a distribution or transport label creates a zero-logs policy. Preserve enough evidence to diagnose faults while avoiding unnecessary collection.
Read hosting options as parts of the design
SwissOctet Veil lists application-stack, onion-address and backup choices. Select the stack your software expects and enough CPU, memory and storage for the workload. Confirm how the actual service handles deployment, service identity and restoration before depending on it. The catalogue's Swiss location is separate from the privacy behaviour of your application.
Keep the service intended for legitimate publishing and authorised users. Plan administrator updates, access reviews and a response to compromised application credentials. An onion publication works best when content, backend exposure and recovery are understandable; the transport should support that plan rather than become an excuse to skip ordinary software security.
Your practical checklist.
- Define public and restricted content before deployment.
- Verify the backend listener's actual exposure.
- Review pages, uploads and external resource requests.
- Protect and test recovery of service-key material.
- Separate client authorisation from application roles.
- Test maintenance and reader journeys through the onion path.
The details that matter.
Does onion hosting make an application anonymous by itself?+
No. Published content, configuration, accounts and operational practices can reveal information. Review the entire service rather than relying on the connection method.
Should every onion site use client authorisation?+
No. Decide from the intended audience. Client authorisation restricts connection access and adds a credential lifecycle; application permissions remain separate.
What must I protect in a recovery copy?+
Site data and configuration need appropriate access controls. Any included service-key material is especially sensitive and must remain private during storage and restoration.
Go to the source.
These references support the technical concepts in this guide. Follow the current documentation before changing a production system.
- Tor Project: Set up your onion service community.torproject.org
- Tor Project: Advanced onion-service settings community.torproject.org
- Tor Project: Client authorisation community.torproject.org
Editorial guidance by SwissOctet. Examples are illustrative. Service specifications, available options and contractual conditions must be verified separately.