介绍
应用可能正常满足用户需求，却同时泄漏用户不需要的信息。本实验中的 DeskLite 已经运行，但状态响应包含内部开发细节。你将调查该响应，修改一个配置开关，并确认服务仍然可用。
你只需具备基本的终端目录切换与文件阅读能力。请求、HTTP 响应、配置开关以及预置的重启命令都会在使用时逐步介绍。这是你的第一个 DevSecOps 闭环：观察风险、修复原因，同时验证安全与正常功能。
观察并修复服务响应
在这一步中，你将阅读 DeskLite 响应，识别不必要的内部信息，并修复导致信息暴露的设置。
DeskLite 是一个小型服务台应用。工作人员需要票据信息，以及服务正在运行的简单提示，不需要内部文件位置或开发诊断信息。这些内部细节是我们要保护的信息；能够读取响应的人就是响应的受众。
服务是持续运行并回答请求的程序。HTTP 请求向 Web 服务索取信息；响应包含状态码和正文。你将使用终端程序 curl 发送请求，因此不需要浏览器或编程知识。
实验已经准备了运行中的服务。只在其预置目录中操作：
cd /home/labex/project/desklite
URL 告诉 curl 应把请求发往哪里。在 http://127.0.0.1:8080/status 中，http 是请求协议，127.0.0.1 表示当前实验机器，8080 选择服务，/status 选择端点，即服务提供的一种特定响应。这里不需要配置网络。
curl http://127.0.0.1:8080/status
正文采用 JSON：花括号内包含有名称的字段及其值。你只需阅读，不需要编写程序。
{
"service": "DeskLite",
"status": "running",
"internal_path": "/opt/labex-desklite/private/settings.ini",
"debug_details": "development diagnostics enabled"
}
service 和 status 对预期受众有用。internal_path 暴露内部文件位置，debug_details 暴露开发信息。知道路径并不自动获得文件访问权，但多余细节可能帮助别人规划进一步调查。这称为信息泄漏。
加上 -i 选项，可以在正文上方显示 HTTP 响应头：
curl -i http://127.0.0.1:8080/status
首行包含 200 OK，表示请求成功。Content-Type: application/json 等响应头描述正文；空行分隔响应头与正文。日期可能变化。HTTP 状态成功不代表响应安全——这里成功返回的响应恰好泄漏了信息。
读取服务配置，也就是应用使用的设置文件：
cat service.conf
[service] 对设置进行分组。以 # 开头的行是解释性注释。debug = true 是一个布尔值开关：true 启用开发诊断，false 禁用诊断。注释将此设置与暴露的状态字段联系起来。
应用配置修复
调试信息有助于开发者调查问题。开发阶段有用的设置，可能并不适合只需要公开状态的受众。DevSecOps 将安全融入开发与运维的共同工作：明确哪些内容应当可见、修改配置，再测试运行结果。
用终端文本编辑器 nano 打开配置。使用方向键移动到设置处。下文使用 Ctrl 快捷键时，按住 Ctrl 再按对应字母：
nano service.conf
只将 debug = true 改为 debug = false，保留 [service] 标题和注释。按 Ctrl+O、Enter 保存，再按 Ctrl+X 退出。确认保存的文件：
cat service.conf
设置现在应该如下：
[service]
## Include development diagnostics in status responses.
debug = false
磁盘上的文件与运行中的程序是两回事。这个服务在启动时读取设置，因此仅保存文件并不会更新响应。课程提供 restart.sh 来应用配置，你不需要自行管理进程。bash 运行这个预置脚本；无需编辑脚本。
bash restart.sh
预期输出：
DeskLite restarted.
再次请求同一端点，并包含响应头：
curl -i http://127.0.0.1:8080/status
应该看到 200 OK 和以下正文：
{
"service": "DeskLite",
"status": "running"
}
两个内部字段都消失了，有用的状态信息仍然保留。如果内部字段还存在，检查是否保存了 service.conf 并执行重启命令。如果脚本报告配置错误，恢复上面展示的分组标题和布尔值拼写，再重试。不要通过替换应用或停止服务来隐藏响应。
同时验证安全与业务
在这一步中，你将确认修复能在再次重启后保留，并且 DeskLite 仍能服务预期用户。
破坏服务也能让响应消失，但同时会失去有用功能。因此需要两类证据：敏感字段已经消失，合法服务仍然工作。健康检查报告服务的基本就绪状态；业务请求测试用户真正需要的功能。
再次重启，确认保存的配置持续生效：
bash restart.sh
再次检查状态：
curl -i http://127.0.0.1:8080/status
预期出现 200 OK、service 和 status，但没有 internal_path 或 debug_details。现在请求健康端点：
curl -i http://127.0.0.1:8080/health
预期为 200 OK，正文如下：
{
"status": "ok"
}
最后，请求业务端点：
curl -i http://127.0.0.1:8080/tickets
预期为 200 OK，并返回原来的票据：
{
"tickets": [
{
"id": 1,
"title": "Printer offline"
}
]
}
仅证明进程健康，还不能证明票据访问正常。这些请求共同表明：信息泄漏已被移除，预期功能仍然可用。curl 还可能显示传输进度；判断时关注 HTTP 状态与正文，而不是进度显示。
结束前，试着解释为什么仅有 200 OK 不能证明安全，为什么只检查健康状态不能证明业务功能正常。这用于帮助你理解，不要求提交书面记录。
总结
你使用 curl 和 curl -i 阅读 HTTP 响应，区分请求成功与响应安全，并把暴露的字段关联到一个布尔配置开关。你保存设置、重启 DeskLite，确认状态、健康检查和票据访问仍然正常，且不再包含内部诊断信息。
你验证了实际配置和运行中的服务，包括再次重启后的行为。这个小型工作流将开发设置、运维行为和安全验证连接起来。接下来的挑战会把相同技能应用到另一个预置服务。
