Wayback machine is an awesome resource for a quick recon. It helps in finding sometimes obscure paths and endpoints specific to that company’s way of naming things, the words and paths that aren’t in any public wordlists. And a quick way to analyze those endpoints when there are too many for a manual approach is to use ffuf or equivalent. But, what if some of those endpoints that aren’t 200 OK according to ffuf are in fact still useful?

The broken puzzle
There are endpoints that end up in wayback machine which don’t make any sense, usually because they seem to belong in js files or html source code (ie. html.onmouseover, innerHTML.onfocus, etc.) and are never, or rarely a part of a proper link (unless if it’s xss payload). And those are pretty useless. But then there are the “broken” ones, the ones that make sense, which, if you’re looking to leave it all to automation may mean you’ll miss some cool stuff.

Putting the pieces together
On one occasion I found myself with a sizable list of seemingly interesting endpoints. It had tokens and the naming of those endpoints suggested a very interesting IDOR. I used ffuf to quickly verify what was worth looking at, and ffuf did found some valid endpoints. Still, being that the list was huge, and it had parameters, I figured, let’s see if I can get something more when attacking the parameters, like xss/ssrf/sqli/rce.
Looking at the list, I noticed that there were similarities within endpoints, as in, some were lacking the token param compared to their pair that actually had it. And then some endpoints implied connection to the overall api, but were giving 403 because, as it turned out, they needed the token param.

Here is an example of two types of 302 redirects depending on the token’s presence:

And here is an example of an endpoint that didn’t have api token, and then how it responded with a valid api token that was found in wayback machine:

The two types of broken links
Now, I pretty much see that there are two types of broken links:
1 — some of the api keys not working for one endpoint, but the other endpoint that has valid api key means that we just got ourselves an additional api endpoint.
2 — some of the endpoints require additional either paths or params or both. It doesn’t have to be a special key, it can just be something that’s essential for the Request to be valid and to give a valid Response, otherwise, it will give 404 or 400, or even 301/302/500, depending on the configuration.