Cyberlium

Secure › Module 5 › Lesson 1

BeginnerModule 5Lesson 1/5

Safe Errors

Fail without leaking stack traces, paths, or SQL — on YOUR $TOY_APP error handlers.

15 min+40 XP3 quiz
Module progress1 of 5

Visual · safe_errors

Safe error handling literacy. $MY_REPO only. Original Cyberlium.

Opening

Users need a generic sorry; logs need detail — both on systems you develop, not stranger stack traces you scrape.

Safe error handling shows generic messages to users while logging detailed diagnostics server-side with correlation IDs. Never return database errors, file paths, or framework versions to clients in production — including your lab deploy of $TOY_APP. Cyberlium teaches try/catch and error middleware patterns in $MY_REPO — not harvesting verbose errors from live shops or classmate APIs. You will NOT publish stranger stack traces in Discord as 'research.' Next: Password Hashing.

1. User-facing vs operator-facing

User sees: 'Something went wrong. Reference ID abc123.' Operator log sees: exception type, stack, request ID — restricted access, chmod 600 notes, no public paste.

On $MY_REPO, wrap one route handler with safe catch that logs internally and returns generic JSON or HTML.

Command guide

Try these commands — User-facing vs operator-facing

═══ TOOLS & WEBSITES ═══ Browse / read these (authorized learning only — stay in YOUR lab / program scope)

Error handling — https://cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet.html OWASP ASVS — https://owasp.org/www-project-application-security-verification-standard/

═══ INSTALL ═══

Linux (Debian/Ubuntu):

Command — copy this

sudo apt install python3

macOS:

Command — copy this

brew install python3

Windows: Download https://python.org/downloads/

═══ LINUX / macOS ═══

Command — copy this

python3 -c "print('Safe errors: generic to client, detail in server log only')"
grep -riE 'traceback|stack trace|Exception as' "$HOME/cyberlium-lab/t17-toy" 2>/dev/null | head -5 || echo 'Review MY_REPO error handlers'

Primary tools to practice this lesson: python3, grep. Reference sites: Error handling (https://cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet.html); OWASP ASVS (https://owasp.org/www-project-application-security-verification-standard/). Run every command in the box — install first, then the usage lines — only on YOUR lab / program scope.

2. Information disclosure is a vulnerability

Verbose SQL errors aid attackers mapping schema. Path leaks reveal deployment layout. Defenders monitor error rates; developers sanitize responses in code you ship.

Probing stranger sites for verbose errors is recon on others — out of scope.

3. Lab fix on owned app

Replace one leaky error response in $TOY_APP with generic message + structured log line.

Ship: before/after error response note. Next: Password Hashing.

4. What you ship: safe error handler for $TOY_APP

Generic user message + server log with correlation ID. $MY_REPO only. chmod 600.

5. What you record before the next lesson

Date. Error handler change. File t17-m05-l01-safe-errors.txt chmod 600.

6. Wrong vs right: stranger apps vs YOUR repo

Worked failure — same MSF word, opposite target. Right never needs a café Wi-Fi or classmate laptop.

  • Wrong

    Return full SQL exception to browser in $TOY_APP. Scrape live shop errors for 'intel.'

  • Right

    Implement safe errors on $TOY_APP. Next: Password Hashing.

Mission: safe error handler

1) Find one verbose error path in $TOY_APP. 2) Return generic client message. 3) Log details server-side with ID. Never harvest stranger error pages.

Stuck? Ask Cyberlium AI Mentor

Correlation ID links user report to log line without exposing internals.

Knowledge Check

1

APPLY: Safe errors on Cyberlium mean:

Multiple choice

Knowledge Check

2

APPLY: True or False: Database error text in HTTP responses helps attackers.

True or False

Knowledge Check

3

APPLY: Operator logs should:

Multiple choice

← Previous

Answer all 3 knowledge checks to continue. (0/3 answered)