Find the server endpoints your scanner can't reach

Dynamic crawlers discover endpoints by simulating user interaction — clicks, form submissions, navigation. Three categories of server endpoints regularly escape this approach:

1  const api = "/application/iuT6ei/";
2  const remove = async (params) => {
3    if (prompt("Enter 'yes' to remove") !== "yes") return;
4    await fetch(api + "interface/remove/handle", {
5      method: "POST", body: JSON.stringify(params)
6    });
7  };
8  const removeByID = (id) => remove({ ident: id });

These functions are never called anywhere on the page. No button triggers them. No link references them. A dynamic crawler simulating user clicks will never execute this code. But the fetch call on line 4 references a live server endpoint that a scanner should test. In our research, we found this exact pattern in a WordPress plugin with 70,000+ active installations.

1  class ApiClient {
2    baseURL = '/api/v2/';
3
4    async sendData(payload) {
5      await fetch(this.baseURL + 'data/ingest', {
6        method: 'POST', body: JSON.stringify(payload)
7      });
8    }
9  }

If this class isn't instantiated on the page, the fetch call on line 5 is invisible to crawlers. Regex URL matching won't find it either — the URL is split across a class field and a method and requires resolving this.baseURL. Industry scanners tested in our research — including Acunetix, Burp Scanner, HCL AppScan, Detectify, and PT BlackBox Scanner — found zero hidden endpoints in code like this.

These are not edge cases. In our testing of five benchmark applications, we found client-side JavaScript bundles containing endpoints for admin panels, authenticated features, disabled functions, and debug interfaces. The server-side code behind these endpoints was live and potentially exploitable.