Skip to main content
Security Auditor — probes a catalogue of sensitive paths on the monitored site without credentials and confirms each one answers 401, 403 or 404, or redirects to a login page.

Access control

An admin panel, API explorer or configuration endpoint that answers 200 to anyone is an open door.

Information disclosure

Debug, log, backup and setup paths leak internals even when they look harmless.
This auditor takes the origin of the monitored URL (for example https://example.com for https://example.com/web/guest/home), picks the path catalogue of the platform declared in the monitored stack, adds any paths configured for the URL, and sends one unauthenticated GET to every path. The first supported platform catalogue is Liferay; every other site uses the generic catalogue. New platforms (for example WordPress) can be added as visitors with their own paths.

​
Preferences

These settings can be configured per monitored URL from the URL’s auditor configuration tab. None is required, so the auditor also runs from Quick Audit. | Preference | Type | Default | Meaning | |---|---|---|---|---| | paths | string | empty | Comma-separated root-relative paths probed in addition to the platform catalogue, for example /wp-admin, /graphql, /actuator. Whitespace is trimmed, a missing leading / is added, and duplicates of catalogue paths are ignored. Extra paths follow the same rules and codes as the catalogue. |

​
How it works

  1. Origin — the scheme and host of the monitored URL. A URL without them is ERROR (501).
  2. Catalogue — the Liferay visitor runs when the monitored stack lists Liferay as vendor or product; otherwise the generic visitor runs. Paths from the paths preference are appended to the selected catalogue.
  3. Baseline — one extra request to a random path that cannot exist (/37audits-probe-<random>). If it answers 2xx, the site serves a soft 404 and a 200 on a sensitive path proves nothing (303).
  4. Probe — every path is requested with GET and the 37 Audits user agent. Up to six requests run in parallel. The URL’s Basic auth, if configured, is sent only to the monitored host.
  5. Follow same-path redirects — a 3xx whose target keeps the same path (canonical www host, http to https, trailing slash) is followed, up to five hops, and the final answer is judged. Following stops, and the path is reported instead, when the target is a login-like URL, another path, a loop, or the sixth hop.
  6. Judge each answer:
    • 401, 403, 404 — protected.
    • 3xx to a URL containing login, signin, sign-in, auth, sso, oauth or saml — protected (redirect to a login page).
    • 2xx — exposed (400), unless the baseline hit a soft 404.
    • 3xx to another path, a loop, or more than five hops — protection unconfirmed (300).
    • any other status (405, 429, 5xx…) — inconclusive (301).
    • no HTTP response — path could not be probed (302); when no request at all got a response the audit is ERROR (500).
  7. Aggregate — ERROR wins, then FAIL, then WARNING; if every path is protected, the audit is SUCCESS (200).

​
What it audits

Every row maps to one checkRule* method and one CheckCode. Codes 200 and 501 belong to the auditor; the others are shared by every platform visitor. CheckCode suffixes use status ranges: 200 success, 300–399 warning, 400–499 fail, 500–599 error.

​
Output documentation

​
Risks and considerations

​
Exposed administration and API endpoints

  • /admin, /manage, /setup and their platform equivalents are the first paths an attacker or a scanner tries. Answering 200 to an anonymous request means either the panel is open or a login form is rendered inline; both deserve a look, and only the second is acceptable.
  • On Liferay, /o/api (the headless API explorer) and /api/jsonws (the JSON web services page) list every remote service the portal exposes. They should be restricted to authenticated users or disabled outside development.

​
Information disclosure

  • /debug, /logs, /backup, /config and /install routinely leak stack traces, credentials, database dumps or installer screens. A 404 is the safest answer; 403 is fine as long as the body does not describe what is being protected.

​
Redirects are followed only when they keep the path

  • A 302 to a login page is treated as protected because the request never reached the resource.
  • Canonical redirects (example.com to www.example.com, http to https, /admin to /admin/) are followed, up to five hops, so the answer of the real URL is judged. The hops are listed in the finding as via "…".
  • A redirect to another path (home page, error page) is reported as a warning because a 200 there says nothing about the probed path. Follow it manually to confirm.
  • Basic auth configured for the monitored URL is not sent to other hosts reached through redirects.

​
Soft 404 sites

  • Single-page applications and some CDNs answer 200 with the app shell for any path. The baseline probe catches this and downgrades the run to a single warning instead of flagging every path as exposed. Until unknown paths answer 404, this auditor cannot tell an exposed path from the app shell.

​
What this auditor does not check

  • It never authenticates and never posts data; it only looks at the status code and the Location header of one GET per path.
  • It does not inspect the response body, so a 200 that renders a login form inline is still reported as exposed. Configure the application to answer 401/403 or redirect to the login page instead.
  • It probes only the listed catalogue plus the paths preference; application-specific paths (for example /wp-admin on WordPress) need either the preference or a visitor for that platform.
  • Basic auth configured for the monitored URL is sent with every probe to the monitored host, so the audit judges the application behind the environment gate, not the gate itself.