* Check the response headers, maybe some information can be given. For example, a **200 response** to **HEAD** with `Content-Length: 55` means that the **HEAD verb can access the info**. But you still need to find a way to exfiltrate that info.
* Use **`TRACE`** verb and if you are very lucky maybe in the response you can see also the **headers added by intermediate proxies** that might be useful.
* Try to [**use other User Agents**](https://github.com/danielmiessler/SecLists/blob/master/Fuzzing/User-Agents/UserAgents.fuzz.txt) to access the resource.
***Fuzz HTTP Headers**: Try using HTTP Proxy **Headers**, HTTP Authentication Basic and NTLM brute-force (with a few combinations only) and other techniques. To do all of this I have created the tool [**fuzzhttpbypass**](https://github.com/carlospolop/fuzzhttpbypass).
* If the page is **behind a proxy**, maybe it's the proxy the one preventing you you to access the private information. Try abusing [**HTTP Request Smuggling**](../../pentesting-web/http-request-smuggling/) **or** [**hop-by-hop headers**](../../pentesting-web/abusing-hop-by-hop-headers.md)**.**
* Try using _**/**_**%2e/**path _(if the access is blocked by a proxy, this could bypass the protection). Try also_ /**%252e**/path (double URL encode)
* Try **Unicode bypass**: _/**%ef%bc%8f**path_ (The URL encoded chars are like "/") so when encoded back it will be _//path_ and maybe you will have already bypassed the _/path_ name check
* Try to **stress the server** sending common GET requests ([It worked for this guy wit Facebook](https://medium.com/@amineaboud/story-of-a-weird-vulnerability-i-found-on-facebook-fc0875eb5125)).