GLPI status endpoint: monitoring without exposing versions

What the GLPI status endpoint is for and when to restrict it

`/status.php` supports monitoring, and its output must be reviewed before it is reachable from outside your network. A team that publishes GLPI behind a reverse proxy usually wants an uptime check that can tell whether the web tier and the application are answering. That need is legitimate, but a status response is also a description of your installation, so the decision is not only whether to monitor it but which parts of the response an outside client should ever see. GLPI is an open-source IT service management platform, distributed under the GNU General Public License version 3 according to the GLPI README, and it is typically reached through a web server and proxy layer that the operator controls. The status page is one of several surfaces that can reveal the installed version and environment, along with the login page, static assets, error pages and response headers.

Before you expose the endpoint, fetch it from outside your network and from inside the monitoring segment, then compare the two responses. Confirm the fields your target GLPI release returns in your own instance rather than relying on a description from another version, because the output can differ between releases and between configurations. Record which values identify the version, the PHP or database layer, or internal host details. Then decide where the check runs: an internal monitor that calls the application directly, a proxy rule that answers the probe without passing the full output upstream, or a restricted path limited to known monitoring addresses. Ask your reverse proxy team to confirm that the rule is enforced at the edge and not only in the application.

Plan for the risk to change over time. Each GLPI upgrade, plugin change or proxy rewrite can alter what the endpoint returns, so add a check of the status output to your upgrade runbook and to any review of exposed services. Keep the detailed status output limited to administrators on the console or an internal network, and document who can reach it. If your provider or integrator offers a review of exposed endpoints as part of a security assessment, ask them to test the status path as a named item in scope, since it is easy to overlook when the rest of the site is locked down.

Which status output to expose and to whom

This table compares three ways to serve the GLPI status check: anonymous reachability, a restricted network path for monitors, and detailed status limited to administrators in the console. Read each row against your own monitoring design, because the right choice depends on who needs to see what and from where. The main takeaway is that the less a response reveals to an unknown requester, the more you rely on network controls and console access for the information operators still need.

Option	When it fits	What the monitor can confirm	What to verify and main trade-off
Anonymous reachability only	Public or semi-public instances where an external uptime check must run without credentials	The web server answers and the status page loads over HTTPS	Confirm exactly what an unauthenticated request returns in your release, including whether any version or environment detail appears. Trade-off: simplest to monitor, but anyone on the internet can see the response.
Restricted network path for monitors	Internal or private deployments where monitoring servers sit on a known network segment	The application is reachable from the monitor's address and the status response is as expected	Confirm that allow-listing applies at the web server or load balancer, and that the monitor's source address is stable. Trade-off: needs firewall and proxy rules to be maintained, and a monitor moving networks can silently go blind.
Detailed status for administrators in the console	When operators need internal health details such as database or cache state during an investigation	Health details are visible to a logged-in administrator in the GLPI console	Confirm the console page requires an authenticated administrator session and that your profiles restrict it. Trade-off: rich information for operators, but it does not help an automated external monitor.
Response changes with requester identity	Any option where you expect different output for signed-in and anonymous requests	Whether the anonymous and authenticated responses differ	Compare both responses from a clean client and from a logged-in session on your installed release. Trade-off: if the output differs, your monitor and your tests must use the matching path.
Monitor depends on a specific response field or string	Alerting rules that match text in the response body	Only that the response contains the expected text	Verify the string on your installed version before writing alert rules, because output can change between releases. Trade-off: brittle checks that break after an upgrade.
Reverse proxy or load balancer in front of GLPI	Deployments behind a shared proxy where client addresses are rewritten	Whether requests arrive from the monitor's real address	Confirm that the proxy passes the original client address and that your allow rules use the address the application sees. Trade-off: a misconfigured forwarding header can either block monitors or open the endpoint more widely than intended.
Logging and alerting on status requests	Environments where repeated probes from unknown sources must be investigated	Frequency, source and result of each status request	Confirm your web server logs status requests and that they reach your log platform. Trade-off: log volume grows with probe frequency, and status logs alone do not show what a requester learned.

Setting up monitoring without exposing version details

This sequence gives the monitor a stable check, confirms what unauthenticated and monitoring clients can read today, and restricts the status path to monitoring addresses. It also verifies that detailed status stays in the authenticated console and that denied requests are logged.

Confirm the web server layout first
The web administrator checks that the web server's document root points to GLPI's public directory and that URL rewriting routes requests through index.php, as described in the installation prerequisites. Confirm that the status path is served through that public layout and not from the installation root. Request the status path through the production hostname and note the path and response code the web server returns. The step is done when you can name the exact location of the status path on your server and the rule that handles it.
Capture unauthenticated and monitoring baselines
Run the status path request from an unauthenticated client on a general network and from the monitoring host. Use the same hostname and TLS settings the monitor will use. Save the status code, response headers and a short body excerpt from each capture. Look for any version string or build detail in the body, and note whether the two responses differ. The step is done when you have two saved captures and a written list of what an unlisted client can read today.
Restrict the path to monitoring addresses
The network or platform team adds an allow rule for the status path at the reverse proxy or web server. The rule permits only the source addresses of the monitoring hosts and refuses everything else. Apply it to the status path alone so the rest of the application keeps its normal access model. If a load balancer sits in front of the server, confirm which address the server sees, because the rule depends on it. The step is done when the monitoring host still gets the expected response and a request from an unlisted address is refused.
Match an expected response in the monitor
Configure the monitor to check the HTTP status code and a stable marker taken from the baseline capture. Avoid parsing or alerting on version text, so the monitor does not depend on the release number. Set the check to fail on any unexpected status code, so a change in behavior raises an alert. Confirm the marker against the documentation for your GLPI release and your own baseline, because body content can change between versions. The step is done when a test run passes and a deliberately wrong expected code produces a failed check.
Verify administrators still see detailed status
Sign in to the console as an administrator and open the status information GLPI provides there. Confirm the console shows the detail your team needs during an incident, including any version information your release presents. Then sign in with a non-administrator account and confirm it cannot reach the same view. Record which details appear in the console so the on-call team knows where to look. The step is done when the administrator view works and the non-administrator account is refused.
Log and test denied requests
Enable access logging for the status path at the proxy or web server. Confirm that each denied request writes an entry with the source address, time, path and response code. Send a test request from an unlisted address and check that the entry appears in the log your security team reviews. Ask the log platform owner where these entries should be forwarded and how long they are kept, since those settings follow your own policy. The step is done when a denied test request is visible in the log.

How monitoring needs differ by environment

A single GLPI instance behind one reverse proxy has one place to enforce the rule and a small set of consumers for the status path. Usually one monitoring probe and a few operators need it. The proxy should refuse /status.php to external clients and allow only the monitoring probe's address, so version and configuration details stay internal. The platform owner who already administers the proxy is usually the right person to approve the rule.

Restrict at the proxy: Deny /status.php for external clients and allow only the monitoring probe's address, enforced in the proxy configuration.
Confirm the probe's needs: Find out which fields the monitoring tool reads and whether it needs anything beyond an up or down result.
Approval: The platform owner signs off, and the security team reviews the rule once before it goes live.
Evidence: Keep the proxy configuration under version control, the commit history, and test output showing that an external request is refused while the probe still succeeds.

Check that the rule survives a proxy reload and that the monitoring host's address is still current after any network change.

Risks of leaving version and status details open

A status page that answers anonymous requests tells an outsider more than most teams expect. The cards below cover what that information reveals, who can read it, and how to confirm that your GLPI instance returns only what monitoring needs.

Version disclosure guides attackers

An exact GLPI version number lets an outsider match your instance against published weaknesses in minutes, without any probing of your application. The control is to keep version strings out of anonymous responses, so monitoring can confirm the service is up without naming the release. Check the response from /status.php on a request with no session and confirm that no version or build string appears in it. Also check the page footer and login page on your public hostname, since the same string often appears there.

Hosting and framework details leak

Response headers and error pages can reveal the web server, PHP version and operating system, which narrows the search for matching exploits. The control is to remove or replace these headers at the reverse proxy and to use generic error pages. Check the headers returned for /status.php and a deliberately invalid path, then confirm that server software and PHP version strings are absent from both.

Internal health data is over-shared

Detailed health output can list database connectivity, cache state, cron status or the count of failing jobs, which helps an attacker time an attack around maintenance windows. The control is to answer anonymous callers with a minimal up or down result and to keep detailed diagnostics in the console behind authentication. Test by calling the public status path from outside your network and confirm that only the minimal result comes back.

Monitors hold broader access than needed

Monitoring tools often receive administrator credentials or unrestricted network paths so they can read detailed status. The control is a dedicated monitoring identity with no profile rights beyond what the check needs, and network rules that allow only the monitoring host to reach the endpoint. Review the monitor's configured account and source addresses, and confirm that a revoked or low-privilege credential still produces the expected check result.

Status path as the only signal

A check that only confirms the status page loads can report healthy while the database, scheduled tasks or mail queue are failing. The control is to pair the public endpoint with checks on the database and on GLPI's automatic actions, which the console reports. Confirm that your monitoring alerts when the database is unreachable with the status page still responding, and that someone receives the alert.

Status requests leave no audit trail

If requests to the status path are not logged, a scanning pattern or a monitor that stops reporting may go unnoticed, and investigators lose a timeline. The control is to log requests at the reverse proxy with source address, time and response code, and to forward those logs to your central store with a set retention period. Confirm that a test request from an unknown address appears in the proxy log and reaches the central log platform.

How to confirm what your GLPI build reveals

Test the status path from outside your trusted network before and after every change. Request /status.php from a machine that has no internal access, then request it again from a logged-in administrator session and from an anonymous session. Record the HTTP status code, the response body and the headers for each case. The goal is to confirm that anonymous visitors receive only the minimal reply you intended, that no GLPI version string or internal detail appears, and that the private status output is unavailable outside the console. Keep the captured responses with your change record so the baseline is repeatable.

Check the web server and reverse proxy logs at the same time. Confirm that the requests you made are logged with the status codes you saw, and that any proxy rule you added for the endpoint is actually matched, since a rule that never fires gives false confidence. Review the logs for requests to /status.php from addresses you did not expect, which can show that a monitoring tool or scanner is probing the endpoint. Also confirm that the document root still points to GLPI's public directory, because a misplaced root can expose files that a status check would never reveal on its own.

Repeat these checks after every GLPI upgrade. The update procedure replaces the application files and then runs the database update step, so a default file or setting can return even though your earlier configuration worked. Read the release notes for the version you are moving to for any change to status output or to the endpoints it depends on, then confirm behavior against the GLPI documentation for that exact release, not an earlier one. Treat any difference from your baseline as a failed check until you have explained it, and record the result in the same place as your pre-change captures.

Limits to confirm in your environment

The status endpoint sits at the boundary between your monitoring, your proxies and your GLPI console, and each of those layers can change what a request returns. The cards below list the points to verify with GLPI, your monitoring vendor and your own network team instead of assuming the default behavior holds.

Status output by release

Ask whether the response body and fields of /status.php differ between the GLPI release you run and the release you plan to move to, including 11.x and 12.x. Your monitoring checks and any parsing rules may depend on a specific format. Re-test the endpoint after each upgrade in a staging copy before production changes, and record the response you expect from each release.

Proxy and cache behavior

Confirm whether any reverse proxy, CDN or load balancer in front of GLPI caches responses to /status.php. A cached reply can show stale health, hide a failed database connection, or serve an old version string. Check the cache rules for that path explicitly, and confirm that the endpoint is not cached for longer than your monitoring interval.

Status-code-only monitoring support

Check whether your monitoring tool can alert on HTTP status codes alone, without matching body text. If it can only parse content, a body change in a future release could trigger false alarms or silent failures. Ask the vendor how the check handles redirects, TLS errors and timeouts, since those cases decide whether an outage is reported correctly.

Allowlists and cloud monitors

If you restrict access to GLPI by IP address, confirm that the source addresses of any cloud-hosted monitor are on the allowlist. Cloud probes often use a published range that changes over time. Plan a review date for that list, and confirm which addresses your monitoring provider uses before you lock the path down.

Console status and profile rights

Confirm which GLPI profile is required to view the private status output in the console, and whether that rights set is held by any operator who should not see system detail. Test the result with a limited account. Do not assume that administrator rights are the only path, and document who can see the output.

Plugin status output

Ask each plugin vendor whether its installed plugins add their own status lines, version fields or diagnostic pages. Plugins can expose information that the core endpoint does not, and a plugin update may change that output. List every installed plugin during your review and check its public-facing responses, not only the core status page.

Questions teams ask before restricting the GLPI status endpoint

How much effort does a GLPI status endpoint review take?

The effort depends mainly on how many ways the status endpoint can be reached and how many systems depend on it. A single Apache or Nginx host with one monitoring tool is a small review. Several web servers, load balancers, reverse proxies and separate monitoring platforms each add a path to test and document. Compliance evidence needs add more work, because the team must show what was tested and what changed. Ask any partner to base the estimate on a written list of entry points, monitors and proxy layers rather than on a flat number.

What drives the cost of restricting status output?

Cost follows the number of moving parts. Main drivers are the count of entry points, the complexity of proxy and load balancer rules, the number of monitors that poll GLPI, and how many environments need the same change, such as test, staging and production. Evidence requirements also matter: a team that needs dated test records and a rollback record will spend more time than one that only needs a configuration change. One-time work covers the review, configuration and testing. Recurring work appears when monitors change, GLPI is upgraded, or the proxy layer is rebuilt, so ask whether a partner will re-check the restriction after each upgrade.

Can our own team restrict the GLPI status endpoint without a partner?

Often yes, if the team has someone comfortable with the web server layout, the proxy configuration and the monitoring tool. The work is mostly configuration: limiting access to the status path by source address or by authenticated request, and confirming that the monitoring checks still succeed. Skills needed include web server administration, reading PHP application logs, and testing monitor behavior from the monitor's own network. A partner adds value when the team lacks those skills, when several environments must match, or when an independent record of the change is required.

How long does the change take to validate?

Validation time depends on the change window, the size of the test environment and how many monitors must be checked. Work can be validated in a test environment first, then moved into production during an approved window. Monitors that run from several networks need each path tested, and a failed check can extend the cycle. No general duration applies, so ask for a timeline tied to your change calendar and to the number of environments you run. Confirm also whether the vendor documentation for your version describes the status output you expect before you start.

What do we need to provide before a status endpoint engagement starts?

Plan to provide a current network diagram showing where GLPI sits, the web server and any reverse proxy or load balancer in front of it, and the networks where monitors run. You will need the source addresses or address ranges of each monitor, administrative access to the web server, proxy and GLPI console, and a named change approver. Also provide the list of monitoring tools and checks that use the status endpoint, so the restriction does not break a working alert. Ask the partner to confirm this list in writing as part of the scope.

Does restricting the status endpoint affect GLPI Network or our support terms?

Confirm this with the vendor and your support contract before making the change. GLPI Network publishes its subscription tiers, including public cloud, private cloud and self-hosted options, and those pages describe what each subscription covers. Whether a change to access controls on a self-hosted instance affects support depends on the terms of your agreement and the configuration you choose. A written change record that lists the restriction, the affected monitors and the rollback steps makes any later support conversation simpler. DeployOpen does not provide vendor support on behalf of GLPI Network.

Will the restriction work with our existing monitoring tools?

It depends on how each monitor reaches GLPI and what it expects in the response. Some monitors check only that the page returns a success code, while others read specific fields. Restricting access by source address works only if the monitor's outbound address is stable, and a monitor behind a shared NAT gateway may share an address with other systems. Test each monitor from its real network path, not from a laptop, and record the result before and after the change.

How DeployOpen works on this

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including GLPI. For the status endpoint and information exposure, we start by mapping what /status.php reveals today, agree which consumers need it, and then restrict the private output to your console while keeping monitoring working.

How we scope

We inventory which GLPI URLs, headers and status outputs are reachable from outside your network today.
We list monitoring tools and load balancers that poll the status endpoint and record what each one needs.
Engagements are fixed-scope, so the written scope names the GLPI instances, web servers and monitoring systems covered.

How we build

We configure the web server so the public document root and URL rewriting expose only the endpoints you approve.
We restrict private status output to the console and test that unauthenticated requests receive no version or environment details.
We verify the monitoring check still works after changes, using the same request path your monitoring system uses.

How we hand over

We deliver a written configuration record with the exact web server rules, the endpoints allowed and the reasons for each.
We provide a test script or checklist so your team can repeat the exposure check after upgrades or proxy changes.
We document the GLPI version-check and upgrade steps so version information is not reintroduced through a later change.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, covering re-testing after each GLPI release.
We can re-run the exposure review when you add a reverse proxy, a CDN or a new monitoring integration.
Support scope and response arrangements are set out in the retainer agreement, so confirm them in writing before work starts.

GLPI status endpoint and information exposure