URL PATH HASHING

Another thing to consider is that hashes are one-way. If you find a URL in a response, let's say "https://www.mysite.com/admin" and hash the URI on the way to the client: "https://www.mysite.com/182745", then when the client makes a request for /182745, you need to know that this is intended for /admin. A hash wouldn't allow this. You could optionally encrypt and base64-encode the URL, which would be reversible. I'd suggest perhaps a few other options:

1. Don't do this - if the URI is giving away too much information about the application, consider modifying the application itself. Further, encrypting the URI is really nothing more than obfuscation anyway. If the payload of a request to /182745 is something that an admin would send, what difference does it make what the URI is?

    

2. Only obfuscate the URIs that you're worried about - this could be as simple as a STREAM profile in the response event to capture and replace sensitive URIs like /admin with something else.

    

when HTTP_RESPONSE { [CRYPTO::hash -alg sha384 [HTTP::path]] { } }

Understand here that an HTTP response doesn't have a URI or path. These are properties of a request. Any given HTTP response could have HTTP headers or response payload that might contain URIs.