AtoM Heratio — Security Assessment Report

Date: 2026-03-07 Assessor: The Archive and Heritage Group (Pty) Ltd Scope: Public-facing AtoM Heratio deployment — PSIS instance (psis.theahg.co.za) Framework Version: 2.8.2

1. Executive Summary

A security assessment of the AtoM Heratio PSIS instance identified 3 critical findings and 2 medium findings related to the Nginx configuration and exposed services. The underlying application layer security (CSP, CSRF, file validation, SSRF protection) was found to be well-implemented following the M0 Security Hardening milestone.

The primary risk for public-facing deployments is the use of Symfony 1.x (end-of-life since 2012) as the application router. This risk is mitigated through defense-in-depth at the Nginx layer and modern PHP 8.3 runtime security. A full application rewrite is not recommended — the cost-benefit analysis strongly favors infrastructure-level hardening.

Risk Summary

2. Infrastructure Assessment

2.1 Technology Stack

2.2 Disk Usage Finding

During the assessment, the server disk usage was found at 87% (2.7 TB of 3.3 TB), up from 16% one week prior. Root cause: the Apache Jena Fuseki triplestore (/var/lib/fuseki/databases/ric) grew to 1.8 TB due to a runaway RiC sync process that executed 1.8 million POST requests continuously since Feb 27.

Recommendation: Stop the Fuseki container, purge the database, and implement sync job safeguards (record limits, disk usage checks) before re-enabling.

3. Findings

Finding 1: SPARQL Endpoint Publicly Accessible (CRITICAL)

Location: /sparql/ proxy in Nginx config Risk: Data exfiltration — anyone on the internet can execute arbitrary SPARQL queries against the triplestore

Evidence:

location ^~ /sparql/ {
    proxy_pass http://192.168.0.112:3030/ric/;
    add_header Access-Control-Allow-Origin "*" always;  # Wildcard CORS
    # No authentication check
}

Impact: An attacker can query all RiC data, extract entity relationships, and enumerate the archive's holdings without authentication.

Remediation: Require Symfony session cookie. See NGINX_SECURITY_HARDENING.md Section 4.

Finding 2: RiC API Endpoints Publicly Accessible (CRITICAL)

Location: /api/ric/, /api/provenance/, /api/editor/ proxies in Nginx config Risk: Information disclosure and potential data modification

Evidence:

location ^~ /api/editor/ {
    proxy_pass http://127.0.0.1:5002/api/editor/;
    # No authentication check
}

Impact: The editor API may allow unauthenticated modifications to RiC data. The search and provenance APIs expose metadata to anonymous users.

Remediation: Require Symfony session cookie on all RiC API endpoints. See NGINX_SECURITY_HARDENING.md Section 4.

Finding 3: Bot Blocker Exempts Sensitive Endpoints (CRITICAL)

Location: /etc/nginx/conf.d/bot-blocker.conf — $api_bypass map Risk: Bot protection is explicitly disabled for SPARQL and RiC endpoints

Evidence:

map $request_uri $api_bypass {
    ~^/sparql/ 1;      # Bots can freely access SPARQL
    ~^/api/ric/ 1;     # Bots can freely access RiC API
    ~^/ricExplorer/ 1; # Bots can freely access RiC Explorer
}

Impact: Even with bot protection enabled, known bad bots (scrapers, AI crawlers) are allowed through to sensitive data endpoints.

Remediation: Remove SPARQL/RiC entries from the bypass map. See NGINX_SECURITY_HARDENING.md Section 4.3.

Finding 4: Missing HSTS Header (MEDIUM)

Location: Nginx site config — security headers section Risk: Downgrade attacks — a man-in-the-middle could intercept the initial HTTP request before the 301 redirect to HTTPS

Evidence: No Strict-Transport-Security header present in server responses.

Remediation: Add HSTS header. See NGINX_SECURITY_HARDENING.md Section 3.2.

Finding 5: Missing Permissions-Policy Header (MEDIUM)

Location: Nginx site config — security headers section Risk: Browser features (camera, microphone, geolocation) are not restricted, which could be exploited if XSS is achieved

Evidence: No Permissions-Policy header present in server responses.

Remediation: Add Permissions-Policy header. See NGINX_SECURITY_HARDENING.md Section 3.2.

Finding 6: No Login-Specific Rate Limiting (LOW)

Location: Nginx site config — login endpoint Risk: Brute force password attacks against the login form

Current state: The general rate limit (zone=slow, 10r/s with burst=40) applies to all requests, but the login endpoint has no stricter limit. fail2ban has a nginx-badbots jail but no login-specific jail.

Remediation: Add dedicated login rate limit (1r/s) and fail2ban jail. See NGINX_SECURITY_HARDENING.md Sections 5.1 and 5.2.

Finding 7: Server Version Exposed (LOW)

Location: Nginx response headers Risk: Information disclosure — reveals Nginx version to potential attackers

Remediation: Set server_tokens off in nginx.conf. See NGINX_SECURITY_HARDENING.md Section 6.1.

Informational Findings

4. Existing Security Controls (Positive Findings)

The following security controls were found to be properly implemented:

5. Architecture Decision: Hybrid vs. Standalone

Decision

The hybrid architecture (Symfony base + Laravel framework + AHG plugins) is the recommended long-term approach. Standalone Heratio (full Laravel rewrite) is parked.

Rationale

Conclusion

The security risk from Symfony 1.4 is theoretical and mitigated, not practical and exploitable. The Nginx hardening documented in this assessment provides more security value than a full application rewrite at a fraction of the cost.

6. Remediation Priority

Total remediation effort: approximately 1.5 hours.

7. Next Assessment

Recommended reassessment in 6 months (September 2026) or after any major infrastructure change.

Items to monitor:

• Elasticsearch 7.x EOL timeline — plan OpenSearch migration
• Ubuntu 22.04 LTS support ends April 2027 — plan upgrade path
• Any Symfony 1.4 zero-day advisories (monitor CVE databases)
• Fuseki container resource usage after re-enabling RiC sync