Probes admin, API and config paths to confirm they need authentication
Origin — the scheme and host of the monitored URL. A URL without them is ERROR (501).
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.
| Platform | Paths |
|---|---|
| Liferay | /group/guest/~/control_panel/manage, /o/api, /api/jsonws, /c/portal/json_service |
| Generic | /admin, /administrator, /api, /api/v1, /dashboard, /control_panel, /manage, /management, /config, /configuration, /settings, /setup, /install, /backup, /logs, /debug, /test, /dev, /development, /internal, /private, /secure, /system, /sys, /root, /superuser |
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).
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.
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.
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).
Aggregate — ERROR wins, then FAIL, then WARNING; if every path is protected, the audit is SUCCESS (200).
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.
| CheckCode | Status | When it fires | Recommendation | Why it matters |
|---|---|---|---|---|
37A-ProtectedUrlAuditor-501 | ERROR | The monitored URL has no scheme or hostname, so there is no origin to probe. | Monitor an absolute URL with scheme and hostname (for example https://example.com/) instead of {url}. | — |
37A-ProtectedUrlAuditor-500 | ERROR | Not one request, the baseline included, got an HTTP response (DNS failure, connection refused, every request timed out). | Make sure {origin} is reachable by the auditor and re-run; last error was {error}. | — |
37A-ProtectedUrlAuditor-303 | WARNING | The baseline request to a random non-existent path answered 2xx (soft 404). The exposed-path rule is skipped for this run. | Make unknown paths on {origin} answer 404, then re-run so exposed paths can be detected. | When unknown paths answer 2xx, an exposed page cannot be told apart from a missing one, so real exposures stay hidden. Soft 404s also get error pages indexed by search engines. |
37A-ProtectedUrlAuditor-400 | FAIL | A sensitive path answered 2xx without authentication, directly or after same-path redirects (the message lists them as via "…"). One check per exposed path. | Require authentication or block {path} on {origin} so it answers 401, 403 or 404 instead of {status}. | Administration consoles, configuration and internal endpoints reachable without login give attackers a direct way to read data or take over the site. Automated scanners probe for these paths constantly. |
37A-ProtectedUrlAuditor-300 | WARNING | A sensitive path ended on a redirect (3xx) that was not followed: its target is another path, the chain loops, or it exceeds five hops, and it does not look like a login page. One check per path; data.redirects lists the hops that were followed. | Confirm {location} requires authentication, or make {path} answer 401, 403 or 404 directly. | The path does not refuse anonymous visitors, it sends them somewhere else. If that destination is not behind a login, the administration or internal page is effectively public. |
37A-ProtectedUrlAuditor-301 | WARNING | A sensitive path answered a status that is neither 2xx, 3xx, 401, 403 nor 404 (for example 405, 429, 500). One check per path. | Make {path} answer 401, 403 or 404 to unauthenticated requests; it currently answers {status}. | Only 401, 403 or 404 prove a path is closed to anonymous visitors. Any other answer leaves open whether an attacker could reach it with a different request. |
37A-ProtectedUrlAuditor-302 | WARNING | A probe got no HTTP response (timeout, reset) while at least one other request did. One check per path. | Make sure {probeUrl} is reachable by the auditor, then re-run; last error was {error}. | A path that could not be probed is a path whose protection is unknown, so an exposed administration or internal page could go unnoticed. |
37A-ProtectedUrlAuditor-200 | SUCCESS | Every path in the catalogue, extra paths included, is protected. Message is All {n} {platform} sensitive paths on "{origin}" answered 401, 403 or 404 or redirected to a login page.; data lists the paths, the extra paths and the status each one returned. | — | — |
| Status | Description | Test logic |
|---|---|---|
| SUCCESS | Every sensitive path of the platform catalogue is protected | Each path answered 401, 403 or 404 (directly or after same-path redirects), or redirected to a login-like URL; the baseline path did not answer 2xx (200). |
| WARNING | Protection could not be confirmed for one or more paths | Redirect to another path, a loop or more than five hops (300); unexpected status such as 405, 429 or 5xx (301); a path with no HTTP response while others answered (302); soft-404 site (303). Several can fire together. |
| FAIL | At least one sensitive path is reachable without authentication | A path answered 2xx and the baseline did not (400). One check per exposed path; warnings for other paths are listed too. |
| ERROR | The auditor could not judge the site | No request got an HTTP response (500); the monitored URL has no scheme or host (501). |
/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.
/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.
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.
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.
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.
This documentation is built and hosted on Mintlify, a developer documentation platform.
Add this auditor to your monitoring setup and start identifying issues on your websites today.