GoAccess reports need their own access policy
GoAccess HTML and WebSocket report exposure, redaction, and measured fingerprint counts.
oAccess parses web server logs and produces an interactive report. It can run in a terminal or generate an HTML dashboard with a WebSocket feed for live updates. The report is often placed under a web server's document root, which makes access control a deployment decision rather than a feature of the analyzer.
The official documentation notes that a static report still needs a web server to be accessed and that the live HTML report uses GoAccess's own WebSocket server. It also documents authentication markers and options, including HTTP authentication fields and WebSocket JWT support in the manual. Those features matter because the report can reveal request paths, status codes, user agents, referrers, remote addresses, and traffic patterns.
What the measurement shows
On 2026-11-08, count-only ZoomEye probes used sub_type=all, page 1, and page size 1. app="GoAccess" returned 0, title="GoAccess" returned 51, and http.body="GoAccess" returned 1,673.
The body count is much larger than the title count because the product name can appear in HTML assets, documentation, source maps, or copied report templates. It is not a count of exposed GoAccess servers. The title count is narrower but can also catch unrelated pages. Both values should be reconciled with owned domains and real report paths.
Where reports leak
An HTML report may contain the full request history for a site. Query strings can include session identifiers, email addresses, API parameters, search terms, or password-reset tokens. Remote-address fields can disclose customer networks. A report generated for troubleshooting can become a historical data set if it is left in a public directory.
The WebSocket server adds a live access path. A report can look static while its real-time endpoint continues to serve updates. Protect the report and the WebSocket route as one application. If the report consumes a token from a cookie, verify that the cookie is scoped to the report host and that cross-site requests cannot reuse it.
Review checklist
Find every generated report in web roots, object storage, shared file systems, and CI artifacts. Set retention and removal dates. Require authentication at the web server or an identity proxy, and test the WebSocket upgrade path through that proxy. Restrict the bind address and TLS settings for GoAccess's live server.
Before publishing a report, redact or aggregate sensitive query parameters and IP addresses. Disable unnecessary panels. Do not place raw log backups in the same directory as the rendered HTML. Review the report's robots.txt and cache headers; an authenticated page should not be cached by a shared proxy.
Defensive baseline
GoAccess is an observability tool, but its report is sensitive operational data. Keep it on an authenticated management surface, protect both HTTP and WebSocket paths, retain only what is needed, and treat body matches as discovery leads rather than proof of exposure.
References
Did you enjoy this article?
Recommend it — Standard Reader surfaces well-loved writing to more readers across the network.