gosec G114 (CWE-676): HTTP server started via http.ListenAndServe without timeouts (DoS/resource exhaustion risk)

[Himashveta]

Summary

gosec flags G114 because the topo-visualizer starts its HTTP server using http.ListenAndServe(":5152", nil) without configuring server timeouts. Missing ReadHeaderTimeout/ReadTimeout/WriteTimeout/IdleTimeout can increase exposure to slow-client resource exhaustion (e.g., slowloris-style), impacting availability.

Location

• pkg/tools/topo-visualizer/server.go (in (*Server).Serve())

Evidence (code)

Current implementation:

func (s *Server) Serve() error {
    loadTemplate()
    http.HandleFunc("/watch", s.watchChanges)
    http.HandleFunc("/", s.home)
    return http.ListenAndServe(":5152", nil)
}

Why this Matters:

When http.ListenAndServe is used directly, the implicit http.Server has zero-value timeouts. Without explicit timeouts:

• the server may keep connections open indefinitely under slow or abusive clients,

• goroutines/file descriptors can be consumed unnecessarily,

• overall service availability can degrade.

Even though /watch upgrades to WebSocket and sends periodic pings, the initial HTTP request/headers (upgrade handshake) still benefits from ReadHeaderTimeout, and other HTTP endpoints (e.g., /) also benefit from standard HTTP server timeouts.

Suggested fix

Create an explicit http.Server and set timeouts (values can be tuned based on expected traffic). Example:

func (s *Server) Serve() error {
    loadTemplate()

    mux := http.NewServeMux()
    mux.HandleFunc("/watch", s.watchChanges)
    mux.HandleFunc("/", s.home)

    srv := &http.Server{
        Addr:              ":5152",
        Handler:           mux,
        ReadHeaderTimeout: 5 * time.Second,
        ReadTimeout:       15 * time.Second,
        WriteTimeout:      15 * time.Second,
        IdleTimeout:       60 * time.Second,
    }
    return srv.ListenAndServe()
}