Feature Idea: Response Modification in NGINX Unit

[flokoe]

Hi there!

I wanted to share an idea for improving the functionality of NGINX Unit, specifically for use cases involving static single-page applications (SPA).

As you may know, SPA's often require a Content-Security-Policy (CSP) with a NONCE-based approach to ensure the security and integrity of their content. However, this poses a challenge when it comes to generating unique NONCEs per
request, since there's no server-side application code to rely on.

To address this issue, I propose adding a simple response modification feature to NGINX Unit, similar in concept to the sub_filter module available in regular NGINX. This feature would allow developers to modify the response content or at least perform a simple search-and-replace of strings within the response body.

This functionality could be implemented through either:

1. A direct configuration option: allowing users to specify a simple regex pattern and replacement string, which would be applied to each response.
2. A hook for njs scripts: enabling developers to write custom JavaScript code that interacts with the response content and applies the desired modifications.

This would be a valuable addition to the toolset, and I'd love to hear your thoughts on this idea!

[lcrilly]

Hi @flokoe , many thanks for the suggestion - I think it's a great idea.

Response filtering through a JavaScript module would be a very flexible solution, much like the js_body_filter directive with NGINX.

Unit already has the ability to insert a random value per request in the response headers, so I think it would look something like this route:

[
  {
    "action": {
      "response_headers": {
        "Content-Security-Policy": "default-src 'self'; script-src 'self' 'nonce-$request_id'"
      },
      "response_filter": "/js_modules/my_csp_sub", // made-up names!
      "share": "/path/to/spa$uri"
    }
  }
]

[flokoe]

This would be awesome!

Personally, I do not have a preference if this would be implemented via njs or in Unit directly (whatever is easier). It may even suffice to start with simple string replacement as a sub goal. Of course, support for regex would be nice in the future.

For the specific use case of CSPs, it would be necessary to support variables as the replacement value. For example, given some static HTML code like this:

<script nonce="UNIT_CSP_PLACEHOLDER">
  // …
</script>

We would need to replace all occurrences of UNIT_CSP_PLACEHOLDER with a random value which is unique per request. E.g. $request_id variable:

[
  {
    "action": {
      "response_headers": {
        "Content-Security-Policy": "default-src 'self'; script-src 'self' 'nonce-$request_id'"
      },
      "response_filter": "/UNIT_CSP_PLACEHOLDER/$request_id/",
      "share": "/path/to/spa$uri"
    }
  }
]