On this page

Anonymous Reporting Systems

Anonymous reporting systems enable individuals to disclose safeguarding concerns, misconduct, or protection issues without revealing their identity to the organisation receiving the report. Unlike confidential reporting where the reporter’s identity is known but protected, anonymous reporting ensures that no technical mechanism exists to identify the reporter, even under legal compulsion or system compromise. This task covers the implementation of anonymous reporting platforms with the security controls necessary to fulfil that guarantee.

Prerequisites

Requirement	Detail
Access	Administrative access to web hosting infrastructure or SaaS platform admin console
Permissions	DNS management for subdomain creation; TLS certificate provisioning rights
Infrastructure	Web server with reverse proxy capability, or SaaS subscription to anonymous reporting platform
Network	Outbound HTTPS (443) for SaaS; inbound HTTPS for self-hosted with appropriate firewall rules
Policy approval	Written approval from safeguarding lead and data protection officer for anonymous reporting
Information	Categories of reportable concerns; intake workflow requirements; case management integration approach
Time	4-8 hours for SaaS deployment; 16-24 hours for self-hosted implementation

Before beginning implementation, confirm organisational commitment to genuine anonymity. Anonymous reporting creates obligations: you cannot subsequently attempt to identify reporters, you must configure systems to prevent inadvertent identification, and you must communicate honestly about anonymity guarantees. If the organisation requires the ability to follow up with reporters or verify claims through dialogue, confidential reporting with identity protection is the appropriate model.

Verify the distinction between anonymous and confidential reporting with stakeholders:

+------------------------------------------------------------------+
|              REPORTING MODEL COMPARISON                          |
+------------------------------------------------------------------+
|                                                                  |
|  ANONYMOUS REPORTING              CONFIDENTIAL REPORTING         |
|  ====================             ======================         |
|                                                                  |
|  Reporter identity:               Reporter identity:             |
|  Unknown to organisation          Known but protected            |
|                                                                  |
|  Technical controls:              Technical controls:            |
|  - No IP logging                  - Access controls on identity  |
|  - No session tracking            - Audit logging of access      |
|  - No metadata retention          - Encryption of PII            |
|                                                                  |
|  Follow-up capability:            Follow-up capability:          |
|  None unless reporter             Direct contact possible        |
|  initiates via blind code         with consent                   |
|                                                                  |
|  Verification:                    Verification:                  |
|  Cannot verify claims             Can clarify with reporter      |
|  with reporter                                                   |
|                                                                  |
|  Legal compulsion:                Legal compulsion:              |
|  Cannot disclose what             Must protect but may be        |
|  is not collected                 compellable                    |
|                                                                  |
+------------------------------------------------------------------+

Figure 1: Anonymous versus confidential reporting model comparison

Procedure

Platform Selection

Evaluate platform options against anonymity requirements. Self-hosted platforms provide complete control over logging and data retention but require ongoing security maintenance. SaaS platforms reduce operational burden but require careful evaluation of the vendor’s anonymity guarantees and data handling practices.
Self-hosted options:
- GlobaLeaks (open source): Purpose-built whistleblowing platform with Tor support, no logging by default, encrypted submissions. Requires Linux server administration. Recommended for organisations with technical capacity and high-risk operating contexts.
- SecureDrop (open source): Designed for media organisations receiving sensitive leaks. Requires dedicated hardware and Tor-only access. Highest security but significant operational complexity.
- Custom web form with anonymisation: Standard form builder with reverse proxy stripping identifying information. Lower security guarantees; suitable only for lower-risk contexts with technical implementation expertise.
SaaS options:
- NAVEX Global EthicsPoint: Enterprise whistleblowing platform with anonymous web and telephone reporting. Verify data processing location and logging practices contractually.
- Convercent: Configurable intake platform with anonymity options. Confirm no IP logging and metadata stripping in service agreement.
- FaceUp: European-hosted platform designed for GDPR compliance. Verify Tor accessibility if required for your context.
Document platform selection rationale including anonymity guarantees, hosting jurisdiction, and operational requirements. For high-risk contexts where reporters face potential retaliation, physical harm, or legal consequences, select platforms with Tor support and no server-side logging capability.
For SaaS platforms, obtain written confirmation from the vendor addressing:
- IP address logging policy (must be disabled or not collected)
- Session cookie and tracking implementation (must not enable reporter correlation)
- Metadata retention on submissions (timestamps, browser information, geolocation)
- Law enforcement request handling process
- Data residency and jurisdictional considerations
- Subprocessor list and data sharing

Infrastructure Preparation

Provision hosting infrastructure for self-hosted deployments. GlobaLeaks requires a dedicated virtual machine or container with the following minimum specifications:

   CPU: 2 cores
   RAM: 4 GB minimum, 8 GB recommended
   Storage: 50 GB SSD (submissions stored encrypted)
   OS: Ubuntu 22.04 LTS or Debian 12
   Network: Public IP or reverse proxy with HTTPS termination

Create the virtual machine in a jurisdiction appropriate for your threat model. For organisations operating in countries with broad surveillance powers, consider hosting in a jurisdiction with stronger privacy protections.

Configure DNS for the reporting subdomain. Use a subdomain that does not reveal the purpose to casual observers while remaining discoverable for those who need it:

   # Example DNS record (add via your DNS provider)
   # Type: A
   # Name: speak (results in speak.example.org)
   # Value: <server-ip-address>
   # TTL: 3600

Avoid names like whistleblower, report, or safeguarding in the subdomain as these may attract attention in network logs or be blocked by restrictive network filters.

Obtain TLS certificate for the reporting subdomain. Use automated certificate provisioning to ensure uninterrupted HTTPS:

   # Install certbot
   sudo apt update && sudo apt install certbot

   # Obtain certificate (standalone mode, before web server installation)
   sudo certbot certonly --standalone -d speak.example.org

   # Certificate files location:
   # /etc/letsencrypt/live/speak.example.org/fullchain.pem
   # /etc/letsencrypt/live/speak.example.org/privkey.pem

Configure firewall rules to permit only necessary traffic:

   # Allow SSH for administration (restrict to known IPs in production)
   sudo ufw allow from <admin-ip>/32 to any port 22

   # Allow HTTPS for reporting interface
   sudo ufw allow 443/tcp

   # Allow HTTP for certificate renewal challenges
   sudo ufw allow 80/tcp

   # Enable firewall
   sudo ufw enable

   # Verify rules
   sudo ufw status verbose

GlobaLeaks Installation

Install GlobaLeaks using the official installation script. The script configures the application, database, and Tor hidden service:

   # Download and run installation script
   wget https://deb.globaleaks.org/install-globaleaks.sh
   chmod +x install-globaleaks.sh
   sudo ./install-globaleaks.sh

The installation process takes 5-10 minutes and produces output indicating completion:

   GlobaLeaks installation completed successfully.

   Access the platform at:
   - Local: https://127.0.0.1:8443
   - Tor: http://<onion-address>.onion

   Complete initial configuration at the admin interface.

Record the Tor onion address for distribution to potential reporters in high-risk contexts. The onion address provides network-level anonymity in addition to application-level anonymity:

   # Retrieve onion address
   sudo cat /var/globaleaks/torhs/hostname

   # Example output:
   # abc123def456ghi789jkl012mno345pqr678stu901vwx234yz567ab.onion

Access the administration interface to complete initial configuration. Connect to https://<server-ip>:8443 or the onion address via Tor Browser. The first connection prompts for administrator account creation.
Create administrator credentials with a strong, unique password. Store credentials in your organisation’s password manager with restricted access:

   Username: admin@example.org (use a functional email, not personal)
   Password: Minimum 16 characters, generated randomly

Configure platform identity and branding through the admin interface. Navigate to Site Settings > Main Configuration:

   Site name: [Organisation name] Reporting
   Site subtitle: Report concerns safely and anonymously

   # Presentation settings
   Logo: Upload organisation logo (max 1MB, PNG or SVG)
   Primary colour: Match organisation brand

   # Anonymity settings (critical)
   Enable Tor: Yes
   Require Tor for submissions: No (unless all reporters have Tor access)
   Enable two-factor authentication for admin: Yes

Configure submission workflow by defining report categories. Navigate to Questionnaires > Default:
Create intake categories matching your safeguarding framework:

   Categories:
   ├── Safeguarding concern (child)
   ├── Safeguarding concern (adult)
   ├── Sexual exploitation or abuse
   ├── Fraud or financial misconduct
   ├── Harassment or discrimination
   ├── Health and safety concern
   ├── Data protection breach
   └── Other concern

For each category, configure appropriate fields. Minimise required fields to reduce barriers to reporting:

   Required fields:
   - Category selection (dropdown)
   - Description of concern (text area, minimum 50 characters)

   Optional fields:
   - Date of incident (date picker)
   - Location (text field)
   - People involved (text area)
   - Supporting files (file upload, 50MB limit)

Configure recipient workflow. Recipients are staff members who receive and process reports. Navigate to Recipients > Add Recipient:

   Recipient 1:
     Name: Safeguarding Lead
     Email: safeguarding-lead@example.org
     PGP Key: [Upload if using encrypted email notifications]
     Categories: All

   Recipient 2:
     Name: Deputy Safeguarding Lead
     Email: deputy-safeguarding@example.org
     PGP Key: [Upload if using encrypted email notifications]
     Categories: All

   Recipient 3:
     Name: HR Director
     Email: hr-director@example.org
     Categories: Harassment or discrimination, Other concern

Assign at least two recipients to each category to ensure reports are processed during staff absence.

Enable the tip-off communication channel. This feature generates a unique code for each submission, allowing reporters to check status and provide additional information without revealing identity:
Navigate to Advanced Settings > Tip Configuration:

   Enable tip-off: Yes
   Tip code length: 16 characters
   Tip expiry: 180 days
   Allow file upload via tip: Yes

The tip-off code functions as a blind communication channel:

   +------------------------------------------------------------------+
   |                    TIP-OFF COMMUNICATION FLOW                    |
   +------------------------------------------------------------------+
   |                                                                  |
   |  Reporter                Platform              Recipient         |
   |     |                       |                      |             |
   |     |---(1) Submit -------->|                      |             |
   |     |       report          |                      |             |
   |     |                       |                      |             |
   |     |<--(2) Receive --------|                      |             |
   |     |       tip code        |                      |             |
   |     |       (e.g. A7B2-     |                      |             |
   |     |        X9K4-M3P1)     |                      |             |
   |     |                       |                      |             |
   |     |                       |---(3) Notify ------->|             |
   |     |                       |       new report     |             |
   |     |                       |                      |             |
   |     |                       |<--(4) Add comment----|             |
   |     |                       |       or question    |             |
   |     |                       |                      |             |
   |     |---(5) Check status -->|                      |             |
   |     |       using tip code  |                      |             |
   |     |                       |                      |             |
   |     |<--(6) View comment----|                      |             |
   |     |       and respond     |                      |             |
   |     |                       |                      |             |
   +------------------------------------------------------------------+

Figure 2: Tip-off code enables bidirectional communication without identity disclosure

Anonymisation Configuration

Verify that IP address logging is disabled. GlobaLeaks disables logging by default, but confirm the configuration:

   # Check logging configuration
   sudo cat /etc/globaleaks/globaleaks.conf | grep -i log

   # Expected output should show:
   # loglevel: ERROR
   # No IP logging directives present

Review application logs to confirm no IP addresses appear:

   # Examine recent log entries
   sudo tail -100 /var/globaleaks/log/globaleaks.log | grep -E "([0-9]{1,3}\.){3}[0-9]{1,3}"

   # Expected: No output (no IP addresses in logs)
   # Problem: Any IP addresses appearing indicate logging misconfiguration

Configure the reverse proxy to strip identifying headers. If placing GlobaLeaks behind nginx or another reverse proxy, ensure forwarded headers do not reach the application:

   server {
       listen 443 ssl http2;
       server_name speak.example.org;

       ssl_certificate /etc/letsencrypt/live/speak.example.org/fullchain.pem;
       ssl_certificate_key /etc/letsencrypt/live/speak.example.org/privkey.pem;

       # Security headers
       add_header X-Content-Type-Options nosniff always;
       add_header X-Frame-Options DENY always;
       add_header Referrer-Policy no-referrer always;

       # Do NOT add X-Forwarded-For or X-Real-IP
       # These headers would compromise reporter anonymity

       location / {
           proxy_pass https://127.0.0.1:8443;
           proxy_ssl_verify off;

           # Strip any incoming identifying headers
           proxy_set_header X-Forwarded-For "";
           proxy_set_header X-Real-IP "";
           proxy_set_header Via "";

           # Set generic headers only
           proxy_set_header Host $host;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

Test the configuration and reload nginx:

   sudo nginx -t
   sudo systemctl reload nginx

Disable web server access logging for the reporting endpoint. Standard access logs record IP addresses, timestamps, and request details that could identify reporters:

   # Within the server block for speak.example.org

   # Disable access logging entirely for this virtual host
   access_log off;

   # Alternatively, log only errors without client IP
   error_log /var/log/nginx/globaleaks-error.log error;

Configure file upload sanitisation to remove metadata from submitted documents. GlobaLeaks sanitises files by default; verify the setting is enabled:
Navigate to Admin > Advanced Settings > Submissions:

   Enable file sanitisation: Yes
   Maximum file size: 50 MB
   Allowed file types: All (or restrict based on operational need)

File sanitisation removes EXIF data from images, author metadata from documents, and other embedded information that could identify the reporter.

Verify anonymisation through test submission. Using Tor Browser from a network outside your organisation:

   Test procedure:
   1. Access reporting URL via Tor Browser
   2. Submit test report with identifying information in content
   3. Upload test file with metadata (photo with GPS data)
   4. Complete submission and record tip code
   5. As administrator, examine submission for metadata leakage
   6. Verify file metadata has been stripped
   7. Check server logs for any identifying information

Accessibility Configuration

Verify keyboard navigation throughout the submission flow. Navigate using Tab, Shift+Tab, Enter, and Space without mouse interaction:

   Accessibility checklist:
   - All form fields reachable via keyboard: Required
   - Focus indicator visible on all interactive elements: Required
   - Form can be submitted via keyboard: Required
   - Skip link present to bypass navigation: Recommended
   - No keyboard traps: Required

Configure appropriate colour contrast. GlobaLeaks allows theme customisation; ensure text meets WCAG 2.1 AA requirements:

   Minimum contrast ratios:
   - Normal text (under 18pt): 4.5:1
   - Large text (18pt+ or 14pt bold): 3:1
   - UI components: 3:1

   # Verify using browser developer tools or online contrast checker
   # Test: body text on background colour
   # Test: link colour on background colour
   # Test: button text on button background

Add alternative text to all images and ensure form labels are properly associated:
Navigate to Site Settings > Accessibility:

   Logo alt text: "[Organisation name] logo"
   Form field labels: Ensure all inputs have associated <label> elements
   Error messages: Configure descriptive error text that identifies the field

Enable multiple access channels for populations with limited internet access. Consider:
- Telephone hotline: Partner with external provider for anonymous telephone intake
- Physical drop box: Secure location for written submissions in areas with limited connectivity
- SMS gateway: For contexts where internet access is restricted but mobile networks function
Document available channels in reporting guidance materials and ensure all channels route to the same case management workflow.
Test with screen reader software to verify accessibility for visually impaired reporters:

   # Testing tools
   # - NVDA (Windows, free): https://www.nvaccess.org/
   # - VoiceOver (macOS/iOS, built-in)
   # - Orca (Linux, free): built into GNOME

   # Test procedure:
   # 1. Navigate to reporting page with screen reader active
   # 2. Verify all content is announced correctly
   # 3. Complete submission using screen reader only
   # 4. Verify error messages are announced
   # 5. Verify confirmation is announced

Integration with Case Management

Determine integration approach based on anonymity requirements. Direct integration with case management systems can create linkability risks; evaluate carefully:

   +------------------------------------------------------------------+
   |               INTEGRATION ARCHITECTURE OPTIONS                   |
   +------------------------------------------------------------------+
   |                                                                  |
   |  Option A: Manual Transfer (Highest Anonymity)                   |
   |  ============================================                    |
   |                                                                  |
   |  [Reporter] --> [Anonymous Platform] --> [Recipient reads]       |
   |                                               |                  |
   |                                               v                  |
   |                                    [Manual case creation]        |
   |                                               |                  |
   |                                               v                  |
   |                                    [Case Management System]      |
   |                                                                  |
   |  Anonymity: Preserved                                            |
   |  Efficiency: Lower (manual data entry)                           |
   |  Audit trail: Separate systems                                   |
   |                                                                  |
   +------------------------------------------------------------------+
   |                                                                  |
   |  Option B: Automated with Sanitisation (Moderate Anonymity)      |
   |  =========================================================       |
   |                                                                  |
   |  [Reporter] --> [Anonymous Platform] --> [API sanitisation]      |
   |                                               |                  |
   |                                               v                  |
   |                                    [Case Management System]      |
   |                                                                  |
   |  Anonymity: Dependent on sanitisation quality                    |
   |  Efficiency: Higher (automated transfer)                         |
   |  Audit trail: Linked via case ID                                 |
   |                                                                  |
   +------------------------------------------------------------------+

Figure 3: Integration architecture options showing trade-off between anonymity and efficiency

For high-risk contexts, use Option A with manual transfer to eliminate any technical linkability.

For manual transfer, establish a documented procedure for recipients:

   Manual transfer procedure:

   1. Recipient accesses GlobaLeaks platform daily (minimum)
   2. For each new submission:
      a. Read report content in GlobaLeaks interface
      b. Create new case in case management system
      c. Transcribe relevant information (not copy-paste to avoid metadata)
      d. Assign initial category and priority
      e. Do NOT include tip code in case management system
   3. Maintain tip code separately for reporter communication
   4. Document only that "report received via anonymous channel"

For automated transfer with sanitisation, configure API integration with metadata stripping. This example uses a webhook to create cases in a generic REST API:

   # Example sanitisation middleware for webhook integration
   # Deploy between GlobaLeaks and case management system

   import hashlib
   import re
   from datetime import datetime
   from flask import Flask, request, jsonify
   import requests

   app = Flask(__name__)

   CASE_MGMT_API = "https://cases.example.org/api/v1"
   API_KEY = "your-api-key-here"  # Store in environment variable

   @app.route("/webhook/report", methods=["POST"])
   def receive_report():
       data = request.json

       # Sanitise submission data
       sanitised = {
           "source": "anonymous_reporting",
           "received_at": datetime.utcnow().isoformat(),
           "category": data.get("category", "uncategorised"),
           "description": sanitise_text(data.get("description", "")),
           # Do NOT include: tip_code, submission_time, any identifiers
       }

       # Forward to case management
       response = requests.post(
           f"{CASE_MGMT_API}/cases",
           json=sanitised,
           headers={"Authorization": f"Bearer {API_KEY}"}
       )

       return jsonify({"status": "received"}), 200

   def sanitise_text(text):
       # Remove potential identifying patterns
       # Remove email addresses
       text = re.sub(r'\b[\w.-]+@[\w.-]+\.\w+\b', '[email removed]', text)
       # Remove phone numbers
       text = re.sub(r'\b\d{3}[-.]?\d{3}[-.]?\d{4}\b', '[phone removed]', text)
       # Remove IP addresses
       text = re.sub(r'\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b', '[IP removed]', text)
       return text

Integration risk

Automated integration creates linkability between the anonymous platform and case management system. If the case management system is compromised, attackers could correlate timestamps or content to narrow reporter identification. Evaluate this risk against operational efficiency gains.

Configure recipient notification without compromising anonymity. Email notifications must not include content that could identify the reporter:
Navigate to Admin > Notifications > Templates:

   New report notification template:

   Subject: New anonymous report received

   Body:
   A new report has been submitted to the anonymous reporting system.

   Category: {category}
   Submission reference: {internal_id}

   Please log in to the platform to review the submission.

   [Do NOT include: submission time, file names, content preview]

Security Hardening

Enable automatic security updates for the operating system:

   # Configure unattended upgrades for security patches
   sudo apt install unattended-upgrades
   sudo dpkg-reconfigure --priority=low unattended-upgrades

   # Verify configuration
   cat /etc/apt/apt.conf.d/20auto-upgrades

   # Expected content:
   # APT::Periodic::Update-Package-Lists "1";
   # APT::Periodic::Unattended-Upgrade "1";

Configure fail2ban to prevent brute-force attacks against the administration interface:

   sudo apt install fail2ban

   # Create GlobaLeaks jail configuration
   sudo tee /etc/fail2ban/jail.d/globaleaks.conf << 'EOF'
   [globaleaks-admin]
   enabled = true
   port = 8443
   filter = globaleaks-admin
   logpath = /var/globaleaks/log/globaleaks.log
   maxretry = 5
   bantime = 3600
   findtime = 600
   EOF

   # Create filter
   sudo tee /etc/fail2ban/filter.d/globaleaks-admin.conf << 'EOF'
   [Definition]
   failregex = Failed login attempt.*<HOST>
   ignoreregex =
   EOF

   sudo systemctl restart fail2ban

Implement backup procedures that maintain encryption at rest. GlobaLeaks encrypts submissions with recipient PGP keys; backups must preserve this encryption:

   # Backup script for GlobaLeaks
   #!/bin/bash
   set -euo pipefail

   BACKUP_DIR="/var/backups/globaleaks"
   DATE=$(date +%Y%m%d-%H%M%S)
   BACKUP_FILE="${BACKUP_DIR}/globaleaks-${DATE}.tar.gz.gpg"

   # Create backup directory
   mkdir -p "${BACKUP_DIR}"

   # Stop service briefly for consistent backup
   sudo systemctl stop globaleaks

   # Create encrypted backup
   tar czf - /var/globaleaks | gpg --symmetric --cipher-algo AES256 \
       --passphrase-file /root/.backup-passphrase \
       -o "${BACKUP_FILE}"

   # Restart service
   sudo systemctl start globaleaks

   # Retain only last 30 days of backups
   find "${BACKUP_DIR}" -name "globaleaks-*.tar.gz.gpg" -mtime +30 -delete

   echo "Backup completed: ${BACKUP_FILE}"

Schedule daily backups:

   # Add to root crontab
   sudo crontab -e

   # Add line:
   0 3 * * * /usr/local/bin/backup-globaleaks.sh >> /var/log/globaleaks-backup.log 2>&1

Configure intrusion detection for the reporting server:

   # Install AIDE (Advanced Intrusion Detection Environment)
   sudo apt install aide

   # Initialise database
   sudo aideinit
   sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

   # Configure daily check
   sudo tee /etc/cron.daily/aide-check << 'EOF'
   #!/bin/bash
   /usr/bin/aide --check | mail -s "AIDE Report - $(hostname)" security@example.org
   EOF

   sudo chmod +x /etc/cron.daily/aide-check

Enable two-factor authentication for all administrator accounts. Navigate to Admin > Users and enforce 2FA:

   For each administrator account:
   1. Click user profile
   2. Enable "Require two-factor authentication"
   3. User must configure TOTP on next login

   Supported 2FA applications:
   - Aegis Authenticator (Android, open source)
   - Raivo OTP (iOS, open source)
   - Google Authenticator
   - Microsoft Authenticator

Document incident response procedures for platform compromise. If the anonymous reporting system is breached, the response must protect historical submissions and reporter identities:

   Platform compromise response:

   Immediate (within 1 hour):
   1. Isolate server from network
   2. Notify safeguarding lead and data protection officer
   3. Preserve system state for forensic analysis

   Assessment (within 24 hours):
   4. Determine scope of compromise
   5. Identify accessed data
   6. Assess whether submission content was accessed
   7. Assess whether any metadata could identify reporters

   Response (based on assessment):
   8. If reporter identification possible:
      - Cannot notify specific reporters (identity unknown)
      - Post notice on platform about breach
      - Consider public notification if significant harm possible
   9. Rebuild platform from clean installation
   10. Restore configuration (not data) from pre-compromise backup
   11. Rotate all credentials
   12. Conduct post-incident review

Verification

Complete verification confirms the anonymous reporting system meets security and anonymity requirements.

Anonymity Verification

Test that reporter identity cannot be determined from system records:

# 1. Submit test report via Tor Browser from external network
#    Record approximate submission time

# 2. Check web server logs for IP addresses
sudo grep -r "$(date +%Y/%m/%d)" /var/log/nginx/ | grep -E "([0-9]{1,3}\.){3}[0-9]{1,3}"
# Expected: No IP addresses corresponding to submission time
# Problem: IP addresses present indicate logging misconfiguration

# 3. Check application logs
sudo grep -i "ip\|address\|client" /var/globaleaks/log/globaleaks.log | tail -50
# Expected: No client identifying information
# Problem: Any client identifiers indicate application misconfiguration

# 4. Examine database for metadata
sudo -u globaleaks psql globaleaks -c "SELECT * FROM submission ORDER BY creation_date DESC LIMIT 1;"
# Expected: No IP address, user agent, or geolocation fields
# Problem: Any identifying fields indicate schema customisation issue

# 5. Test file metadata stripping
# Upload image with GPS EXIF data
# Download as recipient
exiftool downloaded-image.jpg
# Expected: GPS coordinates removed
# Problem: GPS or other identifying metadata present indicates sanitisation failure

Security Verification

Confirm security controls function correctly:

# 1. Verify TLS configuration
openssl s_client -connect speak.example.org:443 -servername speak.example.org < /dev/null 2>/dev/null | openssl x509 -noout -dates
# Expected: Valid certificate with future expiry

# Test TLS version (should reject TLS 1.0 and 1.1)
openssl s_client -connect speak.example.org:443 -tls1 < /dev/null 2>&1 | grep -i "handshake"
# Expected: Handshake failure or no connection

# 2. Verify security headers
curl -sI https://speak.example.org | grep -iE "x-frame|x-content|referrer"
# Expected:
# X-Frame-Options: DENY
# X-Content-Type-Options: nosniff
# Referrer-Policy: no-referrer

# 3. Verify Tor hidden service is accessible
# Using Tor Browser, navigate to onion address
# Expected: Platform loads correctly via .onion URL

# 4. Verify fail2ban is protecting admin interface
# Attempt 6 failed logins from test IP
# Check ban status:
sudo fail2ban-client status globaleaks-admin
# Expected: Test IP appears in banned list

# 5. Verify backup encryption
file /var/backups/globaleaks/globaleaks-*.tar.gz.gpg | head -1
# Expected: "GPG symmetrically encrypted data"

Functional Verification

Confirm end-to-end workflow operates correctly:

Functional test procedure:

1. Access reporting URL via standard browser
   Expected: HTTPS connection, platform loads

2. Access reporting URL via Tor Browser
   Expected: Platform loads via both clearnet and onion address

3. Submit test report with all field types
   - Category selection: Functions
   - Text description: Accepts input
   - Date field: Accepts date
   - File upload: Accepts file within size limit
   Expected: Submission confirmation with tip code

4. Check tip code as reporter
   Expected: Status visible, any recipient comments visible

5. Receive notification as recipient
   Expected: Email notification received (without identifying content)

6. Access submission as recipient
   Expected: Full submission visible in platform

7. Add comment as recipient
   Expected: Comment saved

8. Check comment as reporter (using tip code)
   Expected: Recipient comment visible

Troubleshooting

Symptom	Cause	Resolution
Tor hidden service not accessible	Tor service not running or onion address changed	Check `sudo systemctl status tor`; retrieve current address from `/var/globaleaks/torhs/hostname`
”Connection refused” accessing platform	GlobaLeaks service not running	`sudo systemctl start globaleaks`; check logs with `sudo journalctl -u globaleaks -f`
Certificate errors in browser	TLS certificate expired or misconfigured	Renew certificate: `sudo certbot renew`; verify paths in nginx configuration
Submissions not appearing for recipients	Recipient not assigned to submission category	Admin interface > Recipients > verify category assignments for each recipient
File uploads failing	File exceeds size limit or blocked type	Check configured limits in Admin > Advanced Settings > Submissions; verify file type
”502 Bad Gateway” error	Reverse proxy cannot reach GlobaLeaks backend	Verify GlobaLeaks listening on configured port; check proxy_pass URL in nginx configuration
Email notifications not sent	SMTP configuration incorrect or blocked	Verify SMTP settings in Admin > Notifications; test SMTP connectivity from server
IP addresses appearing in logs	nginx access logging enabled	Add `access_log off;` to nginx server block; restart nginx
File metadata not stripped	Sanitisation disabled or failing	Verify setting in Admin > Advanced Settings; check for sanitisation errors in application logs
Admin interface inaccessible after failed logins	IP banned by fail2ban	Unban with `sudo fail2ban-client set globaleaks-admin unbanip <your-ip>`; reduce maxretry if false positives
Tor Browser shows “onion site requires authentication”	Access control misconfigured on hidden service	Check Tor configuration in `/etc/tor/torrc`; ensure no HiddenServiceAuthorizeClient directive
Submission confirmation not received by reporter	Browser blocked JavaScript or cookies	Platform requires JavaScript; reporter should enable or use different browser
Backup script failing	Permissions or disk space issue	Check disk space with `df -h`; verify backup directory permissions; check script output in log file
Database corruption after power loss	Unclean shutdown	Restore from most recent backup; implement UPS for hosting server
Recipients cannot decrypt file attachments	PGP key expired or incorrect	Update recipient PGP keys in Admin > Recipients; recipients should generate new keys before expiry