Worksheet: What did the error reveal?

Use the small campus service-status application provided in this exercise. You do not need to write an app from scratch.

Before you start

Follow your README setup first. In the full repository the app folder is student; in an instructor-provided kit it is app. In this worksheet app folder always means the folder containing server.mjs and config.mjs.

Read safety. Open the submission template separately to record your work.

In your editor, open submission-template.md and use File → Save As to create my-submission.md beside it. Markdown (.md) is plain text: replace the prompts with your answers; no special formatting software is required. This answer file is separate from the app: config.mjs is the only application file you should change. Use your instructor's submission format if one is specified.

Five terms you need

• Browser/client: the program displaying the page.
• Server: the Node program running in your terminal. It receives requests and sends responses. Here both run on your own computer.
• Configuration: settings controlling a program's behavior without rewriting its main logic.
• Debug mode: a development setting that adds details to help investigate a problem. Details appropriate for a developer may be inappropriate for every visitor.
• JSON: a text format with named fields. In {"status":"operational"}, the field status has the value operational.

An HTTP status is a number describing the result: 200 means success; 503 means the service could not complete the request. A safe error should still report failure, not pretend to succeed.

The public error code is the app's label for the problem, here SERVICE_UNAVAILABLE; it is not a password or the HTTP status number. An upstream service is another service an app relies on. In this exercise that dependency and its timeout are simulated: no other service is contacted.

1. Predict and observe

Before clicking anything, predict: what does an ordinary visitor need to know if a campus service is temporarily unavailable? What might help a developer but not belong in a public response?

Save each response before the next click. Each button replaces the previous response on the page; the app does not keep a history. Select and copy the request line, status and complete JSON into the matching section of my-submission.md. A screenshot is also acceptable if all three are readable. Record both baseline responses before changing the configuration. Do not use the expected example below as evidence of your own run.

1. Select Load working status. Record the request, HTTP status and JSON.
2. Select Trigger simulated failure. This deliberately produces a failure; it does not break your computer or contact a real campus service.
3. Record its status, public error code and the fields inside diagnostics.
4. Identify two details an ordinary visitor does not need. Explain how analogous real details could reveal internal structure to an attacker. Do not claim the fictional values are real credentials.

The response shown comes from the server. Browser developer tools are optional: in the Network panel, select the failure request to inspect the same response.

2. Locate the setting

Open config.mjs in the app folder. Find:

export const debug = true;

true and false are booleans: on/off values, without quotes. export makes the setting available to the supplied server. Keep the rest of the line intact.

The supplied server reads this setting when it starts. With debug enabled, it includes fictional diagnostics. Which boolean value would turn those extra details off? Write your prediction before editing.

3. Repair and restart

1. Change only the boolean value to disable debug output.
2. Save the file. Keep its name config.mjs, not config.mjs.txt.
3. In the terminal running the server, press Ctrl+C.
4. From the same app folder, run node server.mjs again.
5. Refresh the browser, then try both buttons again.

Record the actual responses, not just what you expected. The failure should still be 503 with code SERVICE_UNAVAILABLE, but should no longer include diagnostics. The normal request should still return 200 and a working status.

Why would changing the browser to hide the diagnostics not repair the server? A visitor can inspect the network response or use another HTTP client; information already sent cannot be made private by hiding it on the page.

4. Verify independently

Stop the app server with Ctrl+C. From the app folder, run:

node checks.mjs

The checks start a fresh temporary local server, make HTTP requests directly, and close it. They do not depend on what the page displays. No second terminal is required.

Before repair, the diagnostic-disclosure check is expected to fail. After repair, all checks should pass. Save the output in your submission. Do not edit the checks to make them pass.

Success means four PASS lines followed by All checks passed. The disclosure check can say expected 503, received 503 and still fail: it also checks the response's contents, not just its status number. If it fails, check your saved configuration and the folder you ran it from. Copy the terminal output using the terminal's Copy menu. After checks finish, the local server is stopped; run node server.mjs again only if you need another browser observation, and stop it when finished.

Expected failure response after repair:

{
  "error": "Service temporarily unavailable. Please try again later.",
  "code": "SERVICE_UNAVAILABLE"
}

Returning this safe message does not fix the simulated upstream failure. It fixes the disclosure. Both the 503 status and the public code honestly communicate that the service is still unavailable.

5. Explain and submit

Use submission-template.md to submit your observations, one-line change, test evidence and answers:

1. Why is this security misconfiguration, rather than a vulnerable third-party package?
2. Why keep the 503 status after removing internal details?
3. Why must the fix be on the server rather than just in the page?
4. Why does this single setting not establish that a real system is secure?

No CVE Lite scan is required here: the CLI detects known dependency vulnerabilities, not this configuration flaw.

Troubleshooting

Symptom	What to do
node not found or version below 22	Ask your instructor to help install an approved Node.js version before class.
Cannot find server.mjs	Your terminal is in the wrong folder. Open the folder containing that file, then a new terminal there.
Port 3000 already in use	Stop the previous lesson's server using Ctrl+C in its terminal. Do not randomly kill other processes.
Browser cannot reach the server	Check the terminal is running node server.mjs; visit the exact local URL in the README.
Diagnostics still appear	Confirm you edited the correct app's config.mjs, saved it, then stopped and restarted that server.
Syntax error after editing	Keep export const debug =, the semicolon and an unquoted boolean. Ask the instructor to check the line.
Checks pass but browser looks old	Checks use a fresh server. Restart the browser app's server too; then refresh and request again.