Support for Adding Custom HTTP Response Headers (HSTS) in Janus WebRTC Server

General
1

We have Janus WebRTC Server deployed behind HTTPS and performing a security assessment from the security team.

During the vulnerability scan, the following issue was identified:

HSTS Missing From HTTPS Server (RFC 6797)

The scan indicates that the server does not return the Strict-Transport-Security header in HTTPS responses, which is recommended by RFC 6797 to enforce secure connections and prevent protocol downgrade attacks.

Example header expected:

Strict-Transport-Security: max-age=31536000; includeSubDomains

From my review of the configuration and documentation, it appears that Janus currently does not provide a built-in mechanism to add custom HTTP response headers to responses generated by the internal web server.

Because of this limitation, it is difficult to implement HSTS compliance directly within Janus, which may cause security scanners to flag the service.

Questions

  1. Is there any supported way to add custom HTTP headers (such as Strict-Transport-Security) in the built-in Janus HTTP/HTTPS server?

  2. If not, is this feature planned for future releases?

  3. Is the recommended approach to place Janus behind a reverse proxy (e.g., Nginx/Apache) and add the HSTS header there?

Any guidance from the community or maintainers would be appreciated.

2

This was brought up by someone else already. As we told them, we’re not planning to do that, for a few different reasons:

  1. We don’t recommend enabling the HTTPS support in the Janus HTTP plugin itself. You should just keep HTTP there, and delegate HTTPS support to a proxy instead (see docs). This keeps Janus lighter, and ensures you leave HTTPS and HTTP stuff to a component that’s much better equipped than our tiny integrated web server.
  2. Anything we add to the HTTP plugin should be added to the WebTransport plugin for the same reason. While I think tinkering with headers should be relatively easy with libmicrohttpd, I think it’s harder in libwebsockets. But again, we always recommend proxying the WebSocket API too, so that HTTPS termination is left to more robust components (like nginx or httpd).
1 Like