Introduction
An application can work correctly for its users while revealing information they do not need. In this lab, DeskLite is already running, but its status response includes internal development details. You will investigate that response, change one configuration switch, and confirm that the service remains useful.
You only need basic terminal navigation and file reading. Requests, HTTP responses, configuration switches, and the provided restart command are introduced as you use them. This is your first DevSecOps loop: observe a risk, repair its cause, and verify security and normal behavior together.
Observe and Repair a Service Response
In this step, you will read a DeskLite response, identify unnecessary internal details, and repair the setting that exposes them.
DeskLite is a small help-desk application. Staff need ticket information and a simple indication that the service is running. They do not need internal file locations or development diagnostics. These internal details are the information we want to protect; the people who can read a response are its audience.
A service is a program that stays running and answers requests. An HTTP request asks a web service for something; its response contains a status code and a body. You will use the terminal program curl to send requests, so no browser or programming knowledge is needed.
This lab already has a running service. Work only in its prepared directory:
cd /home/labex/project/desklite
A URL tells curl where to send a request. In http://127.0.0.1:8080/status, http is the request protocol, 127.0.0.1 means this lab machine, 8080 selects the service, and /status selects an endpoint, a particular response the service provides. You do not need to configure networking here.
curl http://127.0.0.1:8080/status
The body is JSON: named fields and their values inside braces. You only need to read it, not write a program.
{
"service": "DeskLite",
"status": "running",
"internal_path": "/opt/labex-desklite/private/settings.ini",
"debug_details": "development diagnostics enabled"
}
service and status help the intended audience. internal_path reveals an internal file location, and debug_details reveals development information. Knowing a path does not automatically grant file access, but unnecessary details can help someone plan further investigation. This is information disclosure.
Add the -i option to include HTTP headers above the body:
curl -i http://127.0.0.1:8080/status
The first line contains 200 OK: the request succeeded. Headers such as Content-Type: application/json describe the body; a blank line separates them from it. Dates can vary. A successful HTTP status does not mean the response is safe—the successful response here leaks information.
Read the service configuration, a file of settings used by the application:
cat service.conf
[service] groups settings. A line beginning with # is an explanatory comment. debug = true is a Boolean switch: true enables development diagnostics; false disables them. The comment connects this setting to the exposed status fields.
Apply the Configuration Fix
Debug information helps developers investigate problems. A setting useful during development may be inappropriate for an audience that only needs a public status. DevSecOps means making security part of development and operations together: define what should be visible, change the configuration, and test the running result.
Open the configuration with nano, a terminal text editor. Use the arrow keys to move to the setting. When using a Ctrl shortcut below, hold Ctrl while pressing the letter:
nano service.conf
Change only debug = true to debug = false. Keep the [service] heading and comment. Save with Ctrl+O, Enter, then exit with Ctrl+X. Confirm the saved file:
cat service.conf
The setting should now read:
[service]
## Include development diagnostics in status responses.
debug = false
A file on disk and a running program are different things. This service reads its settings when it starts, so saving alone does not update its response. The course provides restart.sh to apply the configuration without requiring you to manage processes. bash runs that prepared script; you do not need to edit it.
bash restart.sh
Expected output:
DeskLite restarted.
Now request the same endpoint, including headers:
curl -i http://127.0.0.1:8080/status
Expect 200 OK and this body:
{
"service": "DeskLite",
"status": "running"
}
Both internal fields have disappeared, while the useful status remains. If they are still present, check that you saved service.conf and ran the restart command. If the script reports a configuration error, restore the heading and Boolean spelling shown above, then retry. Do not replace the application or stop it to hide the response.
Verify Security and Business Together
In this step, you will check that the fix survives another restart and that DeskLite still serves its intended users.
Removing a response by breaking the service would remove useful functionality too. We therefore need two kinds of evidence: the sensitive fields are absent, and the legitimate service still works. A health check reports basic service readiness; a business request tests the feature users actually need.
Restart once more to confirm the saved configuration continues to apply:
bash restart.sh
Check the status again:
curl -i http://127.0.0.1:8080/status
Expect 200 OK, service and status, with neither internal_path nor debug_details. Now request the health endpoint:
curl -i http://127.0.0.1:8080/health
Expect 200 OK and:
{
"status": "ok"
}
Finally, request the business endpoint:
curl -i http://127.0.0.1:8080/tickets
Expect 200 OK and the original ticket:
{
"tickets": [
{
"id": 1,
"title": "Printer offline"
}
]
}
A healthy process alone would not prove ticket access still works. Together, these requests show that the disclosure was removed while the intended feature remained available. curl may also display a transfer meter; judge the HTTP status and body, not that meter.
Before finishing, explain to yourself why 200 OK alone does not establish safety, and why a health check alone does not prove that business features still work. This reflection is for your understanding; no written submission is required.
Summary
You used curl and curl -i to read an HTTP response, distinguished a successful request from a safe response, and connected exposed fields to a Boolean configuration switch. You saved the setting, restarted DeskLite, and confirmed that status, health, and ticket access still worked without internal diagnostics.
You verified the actual configuration and running service, including another restart. This small workflow connects development settings, operational behavior, and security verification. The next challenge applies the same skills to another prepared service.
